I'm running svn version 1.2.1 (r15230).
We have a "trunk/db" and a "branches/relaunch/db". I did some work in
relaunch, which was copied on revision 11251. Trunk's head is 11585.
Relaunch's is up to 11592. I would like to merge changes from
relaunch back to trunk. So, I follow the instructions in the SVN
Book, and try this:
$ cd trunk/db
$ svn merge -r 11251:HEAD svn://build/kmrepo/branches/
relaunch/db
A test
A test/config
A test/config/test-config.xml
A test/config/log4j.xml
A test/src
A test/src/java
A test/src/java/foocompany
A
A test/src/java/foocompany/db
A
CU project/DB.mcp
U project
C
C
A
C
U
C
C
C
A
U
C
C
C
A
C
U
U
U
Skipped missing target: 'definitions/CustomerNotes.def'
U build.xml
U .
I see there are a bunch of conflicts I don't want to deal with right
now, so I try to merge part of the changes. I want just the "test"
subtree:
$ svn merge -r 11251:HEAD svn://build/kmrepo/branches/
relaunch/db/test test
(apr_err=200005)
svn: Use to override this restriction
(apr_err=200005)
svn: 'test' is not under version control
, so I try the option:
$ svn merge -r 11251:HEAD svn://build/kmrepo/
branches/relaunch/db/test test
(apr_err=200005)
svn: Use to override this restriction
(apr_err=200005)
svn: 'test' is not under version control
So, I try to add test:
$ mkdir test
$ svn add test
A test
$ svn commit
Adding db/test
Committed revision 11598.
$ svn merge -r 11251:HEAD svn://build/kmrepo/
branches/relaunch/db/test test
(apr_err=20014)
svn: Unable to find repository location for 'svn://build/kmrepo/
branches/relaunch/db/test' in revision 11251
Great. So Subversion chokes because "test" is something I added to
the relaunch branch since 11251. Shouldn't it pick up on this? So, I
try using the first revision that had test:
$ svn log
r11587 | rmann | 2005-08-04 18:06:44 -0700 (Thu, 04 Aug 2005) | 2 lines
A bit of trouble with svn.
r11586 | rmann | 2005-08-04 18:05:02 -0700 (Thu, 04 Aug 2005) | 2 lines
Added unit testing.
I see that test was added in r11586, so:
$ svn merge -r 11586:HEAD svn://build/kmrepo/
branches/relaunch/db/test test
A test/config
A test/config/test-config.xml
A test/config/log4j.xml
But it only lists a few files. Where are all the other files in my
test dir? (There's a source tree):
relaunch/db rmann$ svn status -vu test
11592 11587 rmann test/config
11592 11587 rmann test/config/test-config.xml
11592 11587 rmann test/config/log4j.xml
11592 11586 rmann test/src
11592 11586 rmann test/src/java
11592 11586 rmann test/src/java/foocompany
11592 11586 rmann test/src/java/foocompany/
AbstractTest.java
11592 11586 rmann test/src/java/foocompany/db
11592 11586 rmann test/src/java/foocompany/db/
TestInsert.java
11592 11587 rmann test
Status against revision: 11599
Subversion clearly knows about the other files. What's going on?
Thanks for any assistance.
A final note:
Now, I know the manual says most newcomers want to merge from one
branch to another, but that that's the wrong way to think about it. I
say: it is the RIGHT way to think about it. svn merge should be as
easy to use as:
$ cd Source
$ ls
relaunch/ trunk/
$ svn merge relaunch/db trunk/db
It should do all the stuff that one has to do manually (looking up
revisions, etc) and get the changes I put in relaunch since the
branch was created, 'till now, and apply them to my copy of trunk/db.
Perhaps Subversion requires the branching support it still lacks to
be able to do that.
TIA,

Aug 5, 2005, at 5:53 AM, Ben Collins-Sussman wrote:

Where does the book say that's the "wrong way" to think about it?

Well, perhaps it doesn't say it's "wrong," but it points out that
most new users think about merge one way, and svn thinks about it
another. Rereading it now I guess I, too, misunderstood what the
manual was saying:

The Key Concept Behind Merging
--
You've now seen an example of the svn merge command, and you're
about to see several more. If you're feeling confused about exactly
how merging works, you're not alone. Many users (especially those
new to version control) are initially perplexed about the proper
syntax of the command, and about how and when the feature should be
used. But fear not, this command is actually much simpler than you
think! There's a very easy technique for understanding exactly how
svn merge behaves.

The main source of confusion is the name of the command. The term
merge somehow denotes that branches are combined together, or
that there's some sort of mysterious blending of data going on.
That's not the case. A better name for the command might have been
svn diff-and-apply, because that's all that happens: two repository
trees are compared, and the differences are applied to a working copy.
I never did think merging somehow combined branches. But I do think
of merging as making one branch identical to another.

Aug 5, 2005, at 5:53 AM, Ben Collins-Sussman wrote:

>I see that test was added in r11586, so:
>>
>>
>
You do? Where do you see that? Running 'svn log -v' would
actually show you the list of changed paths in each revision. I
think r11586 doesn't add test/, but rather adds test/config/.
That's why you only see test/config/ being added.

Sure looks to me like test/ was added in r11586, and test/config/ in
r11587:

$ svn log -v test

r11587 | rmann | 2005-08-04 18:06:44 -0700 (Thu, 04 Aug 2005) | 2 lines
Changed paths:
A /
A /
A /

A bit of trouble with svn.

r11586 | rmann | 2005-08-04 18:05:02 -0700 (Thu, 04 Aug 2005) | 2 lines
Changed paths:
A /branches/relaunch/db/test
A /branches/relaunch/db/test/src
A /
A /
A /
A /
A /

Added unit testing.

Still, even trying to merge using r11251 (see the original email),
svn complained about not knowing anything about test/, which makes
things difficult.


>I say: it is the RIGHT way to think about it. svn merge should be
>as easy to use as:
>>
>$ cd Source
>$ ls
>relaunch/ trunk/
>$ svn merge relaunch/db trunk/db
>>
>
Congrats, you've just described merge-tracking. You're preaching
to the choir. :-)

Ah! Good to know I'm not at odds with the choir, the way I usually am.

Fri, Aug 05, 2005 at 01:19:59PM -0700, Rick Mann wrote:
I never did think merging somehow combined branches. But I do think
of merging as making one branch identical to another.

Which is of course not correct. Say branch B was branched from branch A
some time in the past T. Now you merge your changes from B back into A.
Suppose A have changed after T. In this case A and B are not identical
after the merge.

TH, after merging B into A you can think of branch A as the
combination of changes in B and changes in A.

I hope the above made some kind of sense ;-)

Aug 5, 2005, at 3:28 PM, Rick Mann wrote: