Help w/ Branching Mess

[Stephen Quattlebaum <st...@covidimus.net>]

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.

Continued:

5. Working on B2 again, need to merge in changes from T to continue work on
B2.  However, now I'm in a real mess.

The last merge from T to B2 was r1616, before step #4 above.  r1721 to r1740
are the delete of T/Projects, the recreation of T/Projects, and the move of
all the folders in B2 to the new T/Projects.

Have tried the following:

* Merge from T to B2 1616:HEAD, dry-run.  SVN claimed (rightly) that
T/Projects didn't exist in r1616.

* Merge from T@1616 to B2 1616:1721, to get all changes up to just before
the delete/move stuff.  That worked, so I did it w/o dry-run, so now we're
trying to merge from 1721 instead of from 1616.

* Merge from T to B2 1742:HEAD, dry-run.  That skips the delete and move
revisions.  This /almost/ works, but it skips any files that were not in T
before it was renamed and replaced w/ B1, w/ message "Skipped missing
target:...".

* I understand why those files were skipped, so I guess that I need to
include the B1->T 'move' revisions (but will still try to be clever and skip
the T 'delete' revision).  Merge from T to B2 1724:HEAD.  This time the dry
run tells me that it's going to Add every file in the repo, no merges or
conflicts.  Well /that's/ scary.

* Tried all of the following, attempting to quit being clever and just
include the T 'delete'.  (r1721 was the move from T/Projects to a tag, and
r1722 was the creation of the new T/Projects).

$ svn merge -r 1722:HEAD svn+ssh://pathtorepo/trunk/Projects --dry-run
svn: Unable to find repository location for
'svn+ssh://pathtorepo/trunk/Projects' in revision 1722

$ svn merge -r 1722:HEAD svn+ssh://pathtorepo/trunk/Projects@1722 --dry-run
svn: File not found: revision 1722, path '/trunk/Projects'

$ svn merge -r 1721:HEAD svn+ssh://pathtorepo/trunk/Projects@1721 --dry-run
svn: The location for 'svn+ssh://pathtorepo/trunk/Projects' for revision
1844 does not exist in the repository or refers to an unrelated object


So now I don't know what to do.  The most promising path so far appears to
be to do the 1742:HEAD merge, then manually copy and add all the files that
it would skip.  That would get me a B2 that is once again a strict superset
of T, which is what I'm going for.

But then, that also leaves the problem of eventually making B2 be the
mainline.  B2 already has lots of changes from T that were merged after B2
was branched, so it won't really help to give up on doing step #5 above: I'm
probably already going to have to do the "rename T, move B2 to T" process at
least one more time, unless someone has a better idea.  But after that, how
do I keep from getting into this situation again?  In other words, how is
this generally done with SVN: make a long-running branch for new development
while maintaining a deployable branch that is also getting changes, and (the
crux of the matter) get those changes into the long-running branch along the
way.  Is that a bad idea with SVN?  Should one never merge from mainline
into a branch if one plans on later merging that branch back into the
mainline?  (In other words, is a long-running branch doomed to go without
bugfixes and other features added to the trunk until it's time for that
branch to be merged back into trunk?)  Or am I making a more fundamental
mistake that, if corrected, would make all these questions moot?

Thanks!
- Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Help w/ Branching Mess

[Ryan Schmidt <su...@ryandesign.com>]

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@123 url://to/branches/B1@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