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 <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-11 21:47:29 CEST