You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2010/05/11 11:10:08 UTC
Re: How do I determine if svn:mergeinfo is corrupt and how would I
fix it.
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.
>
Re: How do I determine if svn:mergeinfo is corrupt and how would I
fix it.
Posted by Julian Foad <ju...@wandisco.com>.
On Tue, 2010-05-11, Peter Kahn wrote:
> Thanks I have read that doc, but it was a while back so I'll re read
> it.
>
> The issue with the problems we are seeing is that I'm coming in late
> to this situation so most o of these I haven't seen first hand. I
> also discovered that people weren't using --reintegrate and push from
> branch to trunk. That can easily result in extra conflicts.
>
> Here's what I'm telling people to do now
>
> PULL
> svn co URL-branch path-to-workspace
> svn mergeinfo URL-trunk path-to-workspace --show-revs eligible > eligible_revs.txt
>
> svn merge --accept postpone URL-trunk path-to-workspace
> svn mergeinfo URL-trunk path-to-workspace --show-revs eligible > what-is-left-to-merge.txt
> Repeat until there's nothing left that's eiligible. The fact that the
> merge sometimes stops and demands the user resolve before it can
> proceed with the additional ranges through me for a bit. I was still
> operating in 1.4 mental mode. I didn't realize that SVN will break
> up the job based on the merge history to as few merge ranges and paths
> as possible. SVN will stop merging if one of those creates a conflict
> and a subsequent needs to modify the file. (Makes complete sense, I
> can't postpone in that case). I believe that this case is what
> people were calling a conflict on mergeinfo data. So, the
> description wasn't accurate (at least I hope this is the case).
Hi Peter.
That looks good. I hope this means most or all of the problems you
mentioned will go away, but please re-raise if there still are problems.
...
> PUSH
> svn co URL-trunk path-to-workspace
> svn mergeinfo URL-branch path-to-workspace --show-revs eligible > eligible_revs.txt
Actually, "mergeinfo" is not useful here; it will show misleading
results, as it shows what changes are eligible for the "pull" kind of
merging. I don't think "mergeinfo" has a mode for showing what a
re-integrate merge will do. Instead, for this "push" case you could
use:
svn diff --summarize URL-branch URL-trunk
or
svn diff --summarize path-to-branch-workspace path-to-trunk-workspace
(you can't mix a URL with a local working-cpopy path in a diff
--summarize).
> svn merge --reintegrate --accept postpone URL-branch path-to-workspace
>
> svn mergeinfo URL-branch path-to-workspace --show-revs eligible > what-is-left-to-merge.txt
> ... you may need to resolve conflicts and repeat the
> ... merge until there are no more change (see below for details)
>
> svn ci -m "merge from trunk to branch using command: <insert merge command here>" local-path
(I think you meant "merge from branch to trunk ..." here.)
> I think the show-revs will give my users greater confidence about
> determining when they are done. We also plan to add a hudson build
> jobs that checks the elibigle revision queue from trunk to each
> feature branch and nags people if it gets too long.
Heh, that's an interesting idea that I haven't heard of before :-)
- Julian
> On Tue, May 11, 2010 at 7:10 AM, Julian Foad
> <ju...@wandisco.com> wrote:
> 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
>
>
>
> --
> Peter Kahn
> citizenkahn@gmail.com
> pkahnpie1@AIM
> http://www.google.com/profiles/citizenkahn
> Awareness - Intention - Action
Re: How do I determine if svn:mergeinfo is corrupt and how would I
fix it.
Posted by Peter Kahn <ci...@gmail.com>.
Thanks I have read that doc, but it was a while back so I'll re read it.
The issue with the problems we are seeing is that I'm coming in late to this
situation so most o of these I haven't seen first hand. I also discovered
that people weren't using --reintegrate and push from branch to trunk.
That can easily result in extra conflicts.
Here's what I'm telling people to do now
PULL
svn co URL-branch path-to-workspace
svn mergeinfo URL-trunk path-to-workspace --show-revs eligible >
eligible_revs.txt
svn merge --accept postpone URL-trunk path-to-workspace
svn mergeinfo URL-trunk path-to-workspace --show-revs eligible >
what-is-left-to-merge.txt
Repeat until there's nothing left that's eiligible. The fact that the merge
sometimes stops and demands the user resolve before it can proceed with the
additional ranges through me for a bit. I was still operating in 1.4
mental mode. I didn't realize that SVN will break up the job based on the
merge history to as few merge ranges and paths as possible. SVN will stop
merging if one of those creates a conflict and a subsequent needs to modify
the file. (Makes complete sense, I can't postpone in that case). I
believe that this case is what people were calling a conflict on mergeinfo
data. So, the description wasn't accurate (at least I hope this is the
case).
PUSH
svn co URL-trunk path-to-workspace
svn mergeinfo URL-branch path-to-workspace --show-revs eligible >
eligible_revs.txt
svn merge --reintegrate --accept postpone URL-branch path-to-workspace
svn mergeinfo URL-branch path-to-workspace --show-revs eligible >
what-is-left-to-merge.txt
... you may need to resolve conflicts and repeat the
... merge until there are no more change (see below for details)
svn ci -m "merge from trunk to branch using command: <insert merge
command here>" local-path
I think the show-revs will give my users greater confidence about
determining when they are done. We also plan to add a hudson build jobs
that checks the elibigle revision queue from trunk to each feature branch
and nags people if it gets too long.
On Tue, May 11, 2010 at 7:10 AM, Julian Foad <ju...@wandisco.com>wrote:
> 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
>
>
> --
Peter Kahn
citizenkahn@gmail.com
pkahnpie1@AIM
http://www.google.com/profiles/citizenkahn
Awareness - Intention - Action