On Sat, Jan 17, 2004 at 11:57:39AM +0000, Mike Mason wrote:
>
> So going back to Ian's original request, which is to propagate bugfixes
> from "core" (trunk) to "customer version A" (branches/customerA), he
> needs to make those bugfixes in a single commit, where he does not
> change anything else (this is good development practice anyhow). Then he
> needs to merge the change to the branch:
>
> cd /myworkingcopy/trunk/src/flibble
> (apply bugfix to flibble.c)
> svn commit -m "Fixed word wrap bug in flibble" flibble.c
> Commited revision 768.
> cd /myworkingcopy
> svn merge -r 768 trunk branches/customerA
> svn commit -m "Merged r768 (word wrap bug) to customerA branch"
> branches/customerA
>
> Is that about right? Does the merge argument need to be "-r 767:768"
> instead?
>
It does need to be -r 767:768. It doesn't technically need to be
a single revision; he could just use multiple "svn merge" invocations
to get each of them (or perhaps a single one specifying a revision
range, if they happen to be contiguous). One nice feature of merge
is that it takes place in the WC; you can do as many merges as you
want before committing.
Also, your example hints that you keep a WC of your *entire repository*!
That would be a big WC, once you had lots of tags and branches. This
is not necessary; you only really need one WC:
svn co http://foo/svn/trunk mywc
cd mywc
(apply fix to flibble.c)
svn commit -m "Fixed word wrap bug in flibble" flibble.c
Commited revision 768.
svn switch http://foo/svn/branches/customerA
svn merge -r 767:768 http://foo/svn/trunk
svn commit -m "Merged r768 (word wrap bug) to customerA branch"
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 17 15:14:55 2004