I believe what you need to do is every time you synch with the trunk log
the HEAD revision you are synching up to.
For example, you start a new branch at revision XX, you make your
modifications, time passes and it's time to synch. Merge all changes
from the trunk XX to HEAD, mark down the HEAD revision (revision YY for
our example) continue making modifications, time for next synch up,
merge trunk YY to HEAD to your branch. This will only merge the
modifications that have occurred to the trunk since the last synch and
should avoid your first issue of merges failing.
Your problem with ancestry is the fact that you are using the
--ignore-ancestry option. If you use the technique I've outlined you
won't need to use the --ignore-ancestry option.
Another tip is that if you have trouble remembering the revisions you
have and have not merged you can just use svnmerge.py, it makes a note
of which revisions have been merged and which have not which makes all
this synching stuff quite easy.
http://www.orcaware.com/svn/wiki/Svnmerge.py
I hope that helps you Justin,
James
-----Original Message-----
From: Justin Wienckowski [mailto:Jwinky@stacksafe.com]
Sent: Wednesday, August 15, 2007 9:30 AM
To: users@subversion.tigris.org
Subject: Ancestry and Merging Problems - Your Analysis?
Hello everyone,
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.
Project Layout:
/project_foo
----- /trunk
----- /branches
----- /tags
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,
which succeeds.
7) Continue work.
8) At several other points along the way, merge changes from /trunk
into /branches/b2 to "keep it up to date."
The Problem:
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
breaking here?
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?
Many thanks!
-Justin Wienckowski
Senior Software Engineer
jwinky@stacksafe.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 15 20:01:25 2007