Chris Lambrou <Chris.Lambrou_at_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_at_subversion.tigris.org].
- application/pgp-signature attachment: stored
Received on 2009-07-06 14:10:37 CEST