Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[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

Re: How do I determine if svn:mergeinfo is corrupt and how would I fix it.

[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