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
> <julian.foad_at_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_at_gmail.com
> pkahnpie1_at_AIM
> http://www.google.com/profiles/citizenkahn
> Awareness - Intention - Action
Received on 2010-05-13 14:13:25 CEST