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

Re: Help w/ Branching Mess

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-06-07 21:51:44 CEST

On Jun 7, 2007, at 10:21, Stephen Quattlebaum wrote:

> I've potentially gotten myself into a mess, and have two questions:
> how to
> get out, and how to avoid getting there again.
>
> The following set of operations have been performed on our repository:
>
> 1. Branch B1 made from trunk T.
>
> 2. Branch B2 made from trunk T.
>
> (B1 and B2 are "large change" branches for major new features being
> worked
> by different developers. T stays deployable and gets bug-fixes and
> minor
> new features that need to go out before B1 and B2 are ready).
>
> 3. Changes are made in all three branches. B1 and B2 are long-
> lived and
> need the changes from T, so those are occasionally merged into them.
>
> 4. Time for B1 to merge back into trunk T. Couldn't figure out how
> to do
> it, eventually merged all changes from T into B1 (had been merging
> along the
> way anyway), SVN moved T/Projects to a tag (hereafter referred to
> as the
> 'delete' of T), SVN created T/Projects, SVN moved each dir within
> the root
> from B1 to T. This caused badness (invalidated working folders,
> hard-to-trace logs, etc.)
>
> First question: what was the correct thing to do at step #4? A
> reference to
> any existing documentation or a HOWTO would be greatly appreciated.

I don't know how to get out of your current mess, but I can show you
how it could have been avoided.

Let's say you merged all changes from T into B1, and that the
revision of the repository is now 123. At 123, T and B1 now both
contain all the changes that were made in T, and B1 also contains the
additional features that have been developed in B1.

To bring all of the B1 changes back into T, go to a working copy of T
at 123, merge in the difference between T and B1, test, and commit.

$ cd working-copy-of-T

$ svn status
# make sure there's no stray changes in the working copy.

$ svn update -r 123
# be sure to update to the same revision up thru which
# you've already merged into B1.

$ svn merge url://to/T_at_123 url://to/branches/B1_at_123
# this brings into the working copy the difference between T and B1
# at revision 123.

# now test this to make sure it works.

$ svn commit -m "Merging B1 branch into T at revision 123"
# make sure to note the revision number in the commit message.

$ svn rm url://to/B1
# remove the branch so nobody's tempted to commit to it anymore;
# they should be committing to trunk now. you may want to check
# "svn log url://to/B1" first to make sure nobody's committed anything
# while you've been merging.

I _believe_ the above is correct; I'm just typing it directly into
the email and haven't tested it.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 7 21:52:57 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.