[Svnmerge] Lost in Properties

[Raman Gupta]

Thomas F. O'Connell wrote:
> Some background about my setup is in this thread:
> 
> http://www.orcaware.com/pipermail/svnmerge/2007-January/000807.html
> 
> I never satisfactorily resolved the issue from that thread. I'm worried
> about data loss that would affect my ability to keep track of changes
> local to any given branch, but I'm also worried about getting into a
> state of conflict that is beyond my ability to resolve, which is my
> current concern.

See below.

> Here is the use case I'm trying to achieve. If there are better
> practices out there that use svnmerge.py, then I'm all ears.
> 
> trunk
> branches/branch-1
> branches/branch-2
> ...
> branches/branch-n
> 
> With the style of development for this project, each of the branches is
> typically a major feature branch, all of the changes of which eventually
> need to land on trunk. But trunk needs to be left in a state from which
> releases can easily be created. Most minor bug fixes are performed
> directly on trunk. Often, features from the branches will land on trunk
> and then be enhanced in the same branch. And it's nice for branch-x to
> pick up the changes that landed on trunk from branch-y.

I think this is a pretty normal process and one that svnmerge.py
should be able to easily handle, if handled with care.

> But I came into this process with the original svnmerge (the Bourne
> shell edition). I upgraded to svnmerge.py based on community
> recommendations. I've used it successfully in the above scenario thus
> far without error until now, although when I started, rather than using
> -b for svnmerge.py avail and svnmerge.py merge, I was manually leaving
> out a lot of the svnmerge-related revisions. This might've contributed
> to my current problem.

Yes, I would guess (I have to because you still haven't given me a
proplist --verbose as I requested earlier) that your trunk has merge
information for itself, because one of the merge revisions from a
branch was mistakenly merged back to trunk at some point (which could
easily happen if you were not using the -b flag).

Does an "svn pl --verbose trunk" show the trunk itself as one of the
sources? If it does, then that explains why you were having the
problem in the other thread -- when you create a new branch, and try
to use svnmerge.py on it, the integrated property (which contains
trunk as a source) gets copied to the branch. So svnmerge.py thinks
your new branch already has trunk as a source.

> Honestly, I'd like to wind up resetting everything based on the trunk
> and possibly re-initializing all branches, but I'm not even sure about
> the safest way to do this. I've got some changes in the branch currently
> exhibiting the problem that I don't want to lose revision history for.

I think this is a good idea since it seems like your svnmerge.py
information is pretty fubar'ed. What I would do is this (untested):

1) Figure out which revisions have already been merged between trunk
and every branch, and vice-versa. Ditto for revisions that have not
been merged (and therefore are available) but should be blocked. The
svnmerge-integrated and blocked property will reflect these values,
plus some administrative revisions, when you're done.

2) "svn pd svnmerge-integrated" and "svn pd svnmerge-blocked" on every
trunk and branch.

3) On the trunk, execute "svnmerge.py init <branch>" for every branch.

4) On the trunk, execute "svnmerge.py --record-only -r <revlist> merge
-S <branch>" for every branch, where revlist is the list of already
merged revisions from step 1. Include in this list the revision
created in step 2.

5) On the trunk, execute "svnmerge.py -r <revlist> block -S <branch>"
for every branch, where revlist is the list of revisions from step 1
that should be blocked.

6) Repeat steps 3, 4, and 5 for every branch, with trunk as source.

7) From now on, always use -b when merging.

> If I can provide any specific information about my setup, please let me
> know, and I'll be happy to do so.

As I said before, pl --verbose on your trunk and problematic branches
would help.

Cheers,
Raman