> Please, assume the following scenario and point me to the right track:
> A repository: http://server/svn/repos contains the following tree:
Since branches and tags are represented by directories, this directory
layout will be difficult to use.
Instead, I'm assuming that the repository has a slightly different layout:
Let's also prepare directories to keep tags and branches:
$ svn mkdir http://server/svn/repos/tags
$ svn mkdir http://server/svn/repos/branches
> Let's say the tree is at revision 4.
> Step 1:
> Programmer Bprog wants to make a tag (can he/she make a named tag?
> how?) and after that
$ svn cp http://server/svn/repos/trunk http://server/repos/tags/release-1.0
(creating revision 5)
> Step 2:
> he/she wants to make a branch at this point.
$ svn cp http://server/svn/repos/release-1.0
(creating revision 6)
$ svn co http://server/repos/branches/bugfix-branch -d my-bugfix-sandbox
> Step 3:
> Programmer Hprog works further on the main trunk and,
> when he/she arrives at revision 10, they want to merge the branch
> on which Bprog was working (how does the revision numbers
> get modified for his/her branch?) into the main trunk.
assuming Hprog has a working copy of /trunk in .
In this particular case, either one of the following commands will merge the
changes on the bugfix-branch with the working copy:
$ svn merge -r6:10 http://server/repos/branches/bugfix-branch
$ svn merge -r6: http://server/repos/branches/bugfix-branch
$ svn merge http://server/repos/trunk@4 http://server/repos/bugfix-branch
$ svn merge http://server/repos/branches/release-1.0
If there are conflicts (e.g. on file main.c) then resolve them manually and
$ svn resolve main.c
$ svn ci
Revision numbers are global. Changes on either the /branches/whatever or the
/trunk will increase the revision number.
> Step 4:
> They want to make a tag here. How can Bprog continue working
> on his branch (can he/she use the same branch
> or does he/she has to make another one?)?
$ svn cp http://server/svn/repos/trunk http://server/repos/tags/release-1.1
$ svn cp . http://server/repos/tags/release-1.1
It's ok to continue working on the existing branch. Until svn remembers the
merge history, however, subsequent merges from the branch to the main trunk
will require that previously merged changes are not merged again. Use -r
with non-overlapping intervals.
Of course, if you make another branch from trunk after the merge, this
branch will be up to date with the changes that occurred on the main trunk.
This might or might not be what you want, but it will likely reduce the
effort of resolving conflicts during later merges, since the different
versions will have a more recent common ancestor.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Jun 16 16:21:29 2002