On Thursday 14 December 2006 21:45, Swenson, Eric wrote:
> We decided we needed a branch during a period where two developers, in
> particular, had outstanding modifications (not yet checked in) in their
> working copy of the "trunk". One of those developers created the branch
> by using the command:
>
> svn copy <working-copy> <url-to-new-branch>
>
> The documentation suggests that if there are outstanding changes in
> <working-copy> that subversion will do two things:
>
> 1. It will make the new branch correspond to the repository
> versions associated with the url of working-copy (in other words, it
> will do the equivalent of "svn copy <url-of-trunk> <url-of-branch>")
It's actually not <url-of-trunk> but
<urls-of-all-working-copies-maybe-with-different-revision-numbers>.
So if your branching developer had different revisions in his working
directory - either because he or she downgraded some files/dirs manually
using 'svn update -rNN' or by making commits of single files without an 'svn
update' on the working dir - then the new branch will include different
revisions as well ...
Was a 'svn update' made direct before the 'copy'?
If not, then maybe this could have caused the collisions later on, but I'm not
sure about this.
Check the change-set of the revision where the branch was created.
If you don't understand the concept of different revisions (of different
files) in the same working directory then have a look to the svn-book:
http://svnbook.red-bean.com/en/1.0/ch02s03.html#svn-ch-2-sect-3.4
In short:
If you check-out a path at rev 1000, the BASE of your working dir will
be 1000. If you then commit one file which creates rev 1001, this file will be
at rev1001 the rest of the dir will still be at r1000, until you run an
update on it. If you make a lot of single commits and never update your
working directory the difference between the revisions can be get quite
large.
> 2. Check in the outstanding modifications on the branch.
>
> It suggests that this is a shortcut for:
>
> svn copy <url-of-trunk> <url-to-new-branch>
> svn switch <url-to-new-branch>
> svn commit
No it isn't, the working copy/dir is not changed like it would be by 'svn
switch' and 'svn commit'.
A operation like 'svn copy <working-copy> <url-to-new-branch>' only changes
the repository not the working directory. That is still the same and points
still to the old URL, i.e. trunk in this case.
The developer should have done the following to create the branch:
cd <working dir>
svn update
# Check for collisions
# subversion says: "At revision <NN>."
# Make a rep-to-rep (i.e. url-to-url) copy:
svn copy url://host/project/trunk url://host/project/branches/newbranch
# Log message: "Created new branch from trunk@r<NN> because .... "
# Switch your working dir with the modifications to the new branch
svn switch url://host/project/branches/newbranch
# Commit the outstanding modifications
svn commit
In this way you avoid any trouble with mixed revisions in your w.d. and have a
defined point where the branch starts.
To merge you do then
svn co <url-of-trunk> <dir>
cd <dir>
svn merge -r <NN>:HEAD <url-of-the-branch>
> Once this was done, development continued for the group on the
> <url-to-new-branch>. Everything was fine until the time that we wanted
> to merge the branch to the trunk.
>
> We did an:
> svn co <url-of-trunk>
> svn merge -r NNN:HEAD <url-of-new-branch>
The important thing here is the correct value of NNN, I hope you took the
revision when the branch was created.
> The result of the above were TONS of conflicts. When we checked many of
> the conflicts were for files that HAD NOT been modified on the trunk.
> We can find no reason for the conflicts. We underwent a very elaborate
> recovery process where we checked each file for modifications on the
> trunk, and if there had been none, we resolved the conflict with the
> copy from the branch. For the files with changes on the trunk, we did
> manual merges. We do not understand why what we believed to be very
> basic functionality of svn failed for us.
> Any help would be greatly appreciated. Our confidence in subversion has
> decreased dramatically since these two occurrences. -- Eric
I don't think it's a bug or similar in subversion, but some concepts and
operations are confusing so it's easy to mess things up.
best,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 19 19:48:38 2006