I'm the version control admin for a software engineering team, and
one of the developers has come to me with a merging problem. I
*think* I understand what has happened, but I'm far from sure, and
I'd really like to get your ideas on (a) what exactly is causing the
problem, and (b) if anyone has an idea for a more efficient solution
than a manual merge file-by-file.
Sequence of Events:
1) Copy /trunk to /branches/b1
2) Over a period of time, changes are made by developer to /branches/
b1 and by rest of the team to /trunk (approx. 40 revisions)
3) Attempt to update /branches/b1 with the interim changes made to /
trunk (ala svn merge -r XX:HEAD /trunk /branches/b1 where XX is the
revision at which step #1 took place). This merge fails.
4) Copy /trunk to /branches/b2
5) Attempt to merge /branches/b1 into /branches/b2 (ala svn merge -r
XX:HEAD /branches/b1 /branches/b2). This also fails due to a
directory that is deleted and then re-added.
6) Merge /branches/b1 into /branches/b2 using --ignore-ancestry,
7) Continue work.
8) At several other points along the way, merge changes from /trunk
into /branches/b2 to "keep it up to date."
When attempting to merge /branches/b2 back into /trunk, the merge
wants to change a bunch of files that were never actually modified
in /branches/b2 except by updates from /trunk. It's obvious that
ancestry is broken for those objects and SVN isn't realizing that the
version of the objects in /branches/b2 are in fact from an old
revision from /trunk.
However, I'm not incredibly experienced with this stuff, and I'd love
to understand the underlying issue to make sure we avoid it in the
future. Anyone have an analysis about exactly where ancestry is
In addition, any ideas for how to merge /branches/b2 back into /trunk
that would be more efficient than manually merging file-by-file only
those files that are known to have changed?
Senior Software Engineer
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 15 17:29:04 2007