On Fri, Feb 20, 2009 at 09:14:00PM +0000, Trent Nelson wrote:
> On Fri, Feb 20, 2009 at 03:20:32PM -0500, Mark Phippard wrote:
> > On Fri, Feb 20, 2009 at 3:10 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
> > >> I wrote the text that was quoted, and it is not as absolute as has
> > >> been made out. You can still use the branch. The blog you were
> > >
> > > But you can't reintegrate it, right? Which kind of makes it unuseable.
> >
> > Sure you can. This works:
> >
> > $ svn co ^/branch1
> > $ svn ci -m "work on branch"
> > $ svn merge ^/trunk
> > $ svn ci -m "Catch up with trunk"
> >
> > On trunk WC
> > $ svn merge --reintegrate ^/branch1
> > $ svn ci -m "Commit all work from branch1"
> > Committed revision 100
> >
> > Back on branch1
> > $ svn merge --record-only -r100 ^/trunk
> > $ svn ci -m "Mark r100 as merged"
-r100 is semantically equivalent to -r0:100, right? The analogous
operation in svnmerge.py is just `svnmerge block 100`, right? I'm
curious as to whether or not the implicit inclusion of of 0:REV in
your example could lead to misleading mergeinfo being committed.
(We've been using this approach for a few months and everything has
just recently fallen apart; pin-pointing the specific issue is hard,
self-referential mergeinfo is certainly playing a part, but I'm won-
dering if the implicit inclusion of 0->[rev] would go through unnot-
iced if a developer accidentally forgot to sync their branch with
trunk and was doing multiple syncs/re-ints from the same branch.)
For funsies, why -r100 and not -c100? (-c100 seems more appropriate
unless the branch actually has /trunk:0-99 mergeinfo recorded on it,
i.e. had just been sync'd before re-int)
Trent.
Received on 2009-06-08 15:23:23 CEST