[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn merge question

From: Troy Curtis Jr <troycurtisjr_at_gmail.com>
Date: 2007-10-14 03:56:03 CEST

On 10/13/07, Mark Phippard <markphip@gmail.com> wrote:
> On 10/13/07, Troy Curtis Jr <troycurtisjr@gmail.com> wrote:
> > On 10/13/07, Mark Phippard <markphip@gmail.com> wrote:
> > > On 10/13/07, Troy Curtis Jr <troycurtisjr@gmail.com> wrote:
> > > > I've pulled down r27167 of trunk (the latest as of last night) to
> > > > check out the new merge-tracking features. I am using the
> > > > merge-tracking early adopter repository for my tests at the moment and
> > > > I ran into an issue that confused me:
> > > >
> > > > * I'm in /branches/d that I created from r8 of /trunk.
> > > > * 'svn mergeinfo' tells me r0:8 are merged and r8:23 are available for merge.
> > > > * 'svn merge <repo path>/trunk' to merge all the available changes
> > > > (this is the correct usage right?) and it tells me "merging r2 through
> > > > r23 into '.'".
> > > >
> > > > That makes me a little confused, I would expect it to say "merging r8
> > > > through r23" since r8:23 were the available revisions. So I look at a
> > > > long on /trunk and see there is r2, r6, and r8. r2 is a normal commit,
> > > > r6 is a merge from /branches/a and r8 blocks r7 from /branches/a.
> > > >
> > > > Is this a feature or a bug? :)
> > > >
> > > > Note that I am using svnmerge.py right now so maybe there is a
> > > > different usage mode.
> > >
> > > Did you say:
> > >
> > > svn merge -g $R/trunk
> > >
> > > or even:
> > >
> > > svn merge -g
> > >
> > > That is what causes it to determine the revisions to merge.
> > >
> > > --
> > > Thanks
> > >
> > > Mark Phippard
> > > http://markphip.blogspot.com/
> > >
> >
> > OH! So you need to tell merge to be "mergeinfo" aware with '-g'? I
> > suppose that makes sense. Of course I foresee me fielding many
> > questions relating to this in my future :) I would think that the
> > '-g' would be the default case and '--no-mergeinfo' would be the
> > optional case. But that is mainly to mirror the svnmerge.py
> > functionality (and the git merge functionality for that matter).
>
> When I try your example, the following all give me the exact same output:
>
> svn merge $R/trunk
> svn merge -g
> svn merge -g $R/trunk
>
> There has been a lot of recent talk about the revisions mentioned in
> the notifications. I suspect there is a bug (I believe there are
> issues open).
>
> It looks like merge is doing the right thing though. It is just the
> notification that is questionable.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>

I agree that you are probably right, after all you'd expect there to
be conflicts or something happen if you were trying to merge the same
stuff twice!

Troy

-- 
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 14 03:56:14 2007

This is an archived mail posted to the Subversion Dev mailing list.