[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: branching best practice

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-05-20 05:42:56 CEST

On May 19, 2007, at 20:03, Karl Fogel wrote:

> Jon Scott Stevens writes:
>> Say I'm working on a WC off of trunk. I've made a whole bunch of
>> changes. renamed directories, moved files around, blah blah blah.
>> These changes aren't complete and if I checked them back into trunk,
>> they would break the build.
>> I need to hand these changes off to someone else and I don't want to
>> break trunk, so I want to commit these changes onto a branch.
>> What's the best practice steps for doing this? The documentation
>> about branching in the book assumes you are working from an unchanged
>> WC.
> Hi, Jon! One way is this:
> $ svn cp . http://blahblahblah/repos/branches/my_new_branch
> In other words, you can create a branch from a working copy -- even a
> mixed-revision, rearranged working copy :-).

Doesn't this method make it impossible to later merge these changes
back into the trunk with

$ svn merge -r$START:$END http://blahblahblah/repos/branches/
my_new_branch wc_of_trunk

where $START is the revision in which the branch was created and $END
is HEAD or whatever?

> Another way is to create a branch from a pristine revision:
> $ svn cp http://blah/repos/trunk http://blah/repos/branches/
> my_new_branch
> Then switch your working copy to that branch:
> $ svn switch http://blah/repos/branches/my_new_branch
> (Note that that preserves your local changes.) Then commit the
> changes:
> $ svn commit
> ...perhaps after testing them to make sure everything still works.

This is the method I would advocate.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 20 05:43:45 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.