Hi Peter.
The mergeinfo "corruption" may be real, but just as likely it doesn't
work the way you expect, or Subversion is being asked to perform
combinations of merging that it doesn't support automatically. It seems
likely that even if there is some "corrupt" merge info, that is only a
part of the problem. It sounds like you might benefit from
understanding better how Subversion's merging works "on the inside"
which will give you the rationale for what it can and can't do "on the
outside".
If that's the case, have a look right at the end of this article
<http://www.collab.net/community/subversion/articles/merge-info.html> at
the list of "Parting Thoughts" which says how to stick to the kinds of
merging that Subversion can cope with. (That article is mostly the
intricate detail of svn:mergeinfo which you really don't want to know.)
Also, WANdisco has an upcoming free training webinar on "Branching and
Merging" which could be useful if you can wait till July 14:
<http://wandisco.com/webinar/subversion/training>.
As for the specific issues you mention, I can't comment much without
seeing the precise detail. It would be a good idea to raise each one as
a separate query, giving a full transcript of input and output and what
you think is wrong.
Regards,
- Julian
> I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know
> how I'd make a determination and what resources are out there to help
> fix problems?
>
> Here’s the issue. My team recently moved to agile and uses feature
> branches (story branches really) where different teams work on the
> same sources concurrently. As the story achieves a high state of
> readiness the team merges to trunk. The merges are taking days or
> weeks due to missing changes, unexpected changes, and conflicts. We
> are talking about teams of 5-10 people and the effort/churn seems way
> to high.
>
> People use the this merge pattern
>
> a) PULL - merge trunk-to-branch, resolve, test, commit
>
> b) PUSH - merge branch-to-trunk, resolve, test, commit
>
> c) Recreate branch (or usually create new story branch and drop old
> since it's done)
>
> By the end of this the branch and trunk should be in alignment.
>
> Problems we are seeing:
>
> 1. changes not reported during trunk-to-branch merge show up in
> subsequent branch-to-trunk
> 2. conflicts on svn:mergefinfo properties during merge
> 3. file missing, but local edit on new file added in branch and
> pushed to trunk
> 4. incoming + local delete (file deleted on trunk and branch
> shows as conflict)
>
> (1) Should not be happening. The pull from branch to trunk should put
> the two in sync for all changes already on trunk. The changes in
> branch-to-trunk merge are changes that happened on the trunk. So in
> the first merge they should have propagated to branch but didn’t. This
> points to corruption in mergeinfo data which would “hide” trunk
> changes.
>
> (2) Should not be happening. SVN should be managing the changes in the
> merge tracking. This also points to corruption in the mergeinfo data
>
> (3) Should not be happening. This is a case of a new file added on
> branch. It should show up as a new file added to trunk. This also
> points to corruption in the merge info data.
>
> (4) I believe this is a SVN bug and that we can’t fix this. Still if
> this were our only problem I'd be happy
>
> We are currently on svn 1.5.x server with clients using svn 1.6.x and
> svn+ssh for connecting. We plan to go up to the latest and greatest
> SVN since some fixes may impact our problems.
>
> Still, it sure looks like our mergeinfo data is wrong.
>
> * Merges that don't report all changes
> * Conflicts in merge of mergeinfo properites
>
> Any good places for me to start looking?
>
>
>
> FYI, I also posted this to Stackoverflow, but thus far "move to git"
> has been the only response and that's not really an option for me at
> present.
>
Received on 2010-05-11 13:10:44 CEST