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 confirmed that you are right. I also did 'svn merge -r8:23
$R/trunk' and the result was the same, except that the output said
"Merging r9 through r23 into '.'".
Has there been any discussion or suggestions about allowing the
specification of relative paths? One of the really nice improvements
to svnmerge was not having to use full URLs every time. I know that
the requirements are a little different because with svnmerge you
always had to 'svnmerge init $URL' first and it could count on having
a directory property there with all the possibilities. The built-in
subversion doesn't necessarily have that luxury. But perhaps some
kind of notification that represents the root URL of the current
working copy?
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 Tue Oct 16 13:45:45 2007