Nico Kadel-Garcia wrote:
> Duncan Murdoch wrote:
>> To start, assume:
>>
>> A and B each copy the trunk to a branch.
>> A renames a file and commits on his branch.
>> B edits the same file and commits on his branch.
>> Both switch back to the trunk, and merge their respective branches
>> into their working copies.
>>
>> Now what should happen, so that they can be sure the conflict will be
>> reported?
>
> Both programmers should be updating from the trunk occasionally.
> Whoever is ready to merge back to the trunk first, does so. Then the
> next update *from* the trunk for the other programmer has the
> changes. If the "move" happens first, well and good, the second
> programmer sees this re-arrangement of their material occur and may
> have a conflict reported.
>
> If the "move" happens second, then well and good, the changes have
> been integrated to the trunk and back out to the second branch, and
> its results can be monitored.
>
> The problem seems to be in communication, and in sharing simultaneous
> branches and failing to commit the changes when they occur, rather
> than much later after additional changes have been made.
Nope. Or, at least, this fails miserably (changes *LOST*) when I test:
# First, the full setup recipe:
$ svnadmin create test
$ mkdir tmp
$ cd tmp/
$ svn co svn://loon/test .
Checked out revision 0.
$ mkdir trunk
$ mkdir branches
$ svn add trunk/ branches/
A trunk
A branches
$ svn ci -m "Created trunk and branches directories"
Adding branches
Adding trunk
Committed revision 1.
$ cd trunk
$ echo "Hello" > foo.txt; svn add foo.txt
A foo.txt
$ svn ci -m "Initial creation of foo.txt"
Adding trunk/foo.txt
Transmitting file data .
Committed revision 2.
$ cd ..
$ svn cp trunk branches/branch1
A branches/branch1
$ svn cp trunk branches/branch2
A branches/branch2
$ svn ci -m "Created branches"
Adding branches/branch1
Adding branches/branch1/foo.txt
Adding branches/branch2
Adding branches/branch2/foo.txt
Committed revision 3.
$ echo "Goodbye" > branches/branch1/foo.txt
$ svn mv branches/branch2/foo.txt branches/branch2/bar.txt
A branches/branch2/bar.txt
D branches/branch2/foo.txt
$ svn ci branches/branch2 -m "Committing rename"
Adding branches/branch2/bar.txt
Deleting branches/branch2/foo.txt
Committed revision 4.
$ svn ci branches/branch1 -m "Committing edit"
Sending branches/branch1/foo.txt
Transmitting file data .
Committed revision 5.
$ cd trunk
$ svn merge -r3:4 svn://loon/test/branches/branch2 .
D foo.txt
A bar.txt
$ svn ci -m "Merged rename into trunk"
Adding trunk/bar.txt
Deleting trunk/foo.txt
Committed revision 6.
# At this point, trunk has the rename merged in, while branch1 has the
edited (but not renamed) file. If we try to merge branch1 into trunk,
we get:
$ svn merge -r3:5 --dry-run svn://loon/test/branches/branch1 .
Skipped missing target: 'foo.txt'
# So, we can't get the change to foo.txt applied to bar.txt directly.
But you said to do an update from trunk, right? So, let's do that: grab
all of the changes to trunk since the branch was created:
$ cd ../branches/branch1/
$ svn merge -r3:HEAD svn://loon/test/trunk .
D foo.txt
A bar.txt
# Doesn't look promising--it didn't raise a conflict. But let's check
the directory:
$ ls
bar.txt
# Hrm, only one file, which is what there should be; let's check the
contents:
$ cat bar.txt
Hello
# Oops! What happened to the change we made? (It's safely tucked away
in revision 5, but there's no good way to get it re-applied to the
branch, or to trunk...)
OK, Nico: what did I do wrong? It sure looks to me as if branches are
not the solution--in fact, they make it more likely that changes could
quietly disappear, which is the exact opposite of what we want!
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 26 22:10:20 2006