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_at_1722 --dry-run
svn: File not found: revision 1722, path '/trunk/Projects'
$ svn merge -r 1721:HEAD svn+ssh://pathtorepo/trunk/Projects_at_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
Received on Thu Jun 7 17:23:10 2007