Resynchronising svn:mergeinfo

[Chris Lambrou <Ch...@grantadesign.com>]

After a recent Subversion upgrade from 1.3 to 1.6, I've created a
maintenance branch for a release, which is a copy of trunk. One or two
developers have back-ported some subsequent bug fixes on trunk to this
feature branch. They did this using the Merge feature in TortoiseSVN,
and when committing the changes, rather than committing all of the
changes, they only committed the changes to the source files they
expected to be changed by the merge. They didn't commit the dozens of
other files and folders that only had property changes, to
svn:mergeinfo. This now gives rise to two questions:

 

1.       Why were there so many changes to the svn:mergeinfo property on
apparently unrelated files?

2.       What are my options for fixing this so that I'll be able to
automatically reintegrate changes on the maintenance branch back to
trunk? I've tried to do this already, and the reintegration fails with
the message 'Reintegration can only be used if revisions <xxxx> through
<yyyy> were previously merged from <trunk> to the reintegrate source,
but this is not the case: (revision numbers and URLs deliberately
omitted).

 

Regards,

 

 

Chris

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2368320

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Resynchronising svn:mergeinfo

[Greg Troxel <gd...@ir.bbn.com>]

Chris Lambrou <Ch...@grantadesign.com> writes:

> After a recent Subversion upgrade from 1.3 to 1.6, I've created a
> maintenance branch for a release, which is a copy of trunk. One or two
> developers have back-ported some subsequent bug fixes on trunk to this
> feature branch. They did this using the Merge feature in TortoiseSVN,
> and when committing the changes, rather than committing all of the
> changes, they only committed the changes to the source files they
> expected to be changed by the merge. They didn't commit the dozens of
> other files and folders that only had property changes, to
> svn:mergeinfo. This now gives rise to two questions:

You need to have a CM policy that merges may only be done at top level
and that commit must be done at top level.  And a rule that people have
to run 'svn diff' before commit, and review and understand all the
changes.  You may need extra rules for TortoiseSVN users, but I don't
know what the pitfalls are.  Unfortunately people need to understand
quite a bit to handle merges.  It's arguably broken for a tool to allow
committing other than the point at which merge was done, at least for
regular users - committing parts of the merge is almost always wrong.

> 1.       Why were there so many changes to the svn:mergeinfo property on
> apparently unrelated files?

In an ideal world, only the module root would have had a property
change, because all previous merges would have been done at the module
root.  Subversion 1.5.0-3 or so added subtree mergeinfo from svn copy.
One of my repositories had a lot of subtree mergeinfo and I just nuked
it.  When a file or directory has mergeinfo, then a change to mergeinfo
at module root has to also add the same thing to the deep-inside
mergeinfo, because the rule is that the per-file property overrides the
top-level property.

> 2.       What are my options for fixing this so that I'll be able to
> automatically reintegrate changes on the maintenance branch back to
> trunk? I've tried to do this already, and the reintegration fails with
> the message 'Reintegration can only be used if revisions <xxxx> through
> <yyyy> were previously merged from <trunk> to the reintegrate source,
> but this is not the case: (revision numbers and URLs deliberately
> omitted).

I would

0. call a halt to merging

1. revert the bad merge

2. investigate the subtree mergeinfo and remove most/all of it with svn
   propdel.  

3. train your people in how to merge correctly

4. start merging again.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2368345

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].