You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Troy Curtis Jr <tr...@gmail.com> on 2007/10/13 16:13:28 UTC
svn merge question
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.
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
Re: svn merge question
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/17/07, Jack Repenning <jr...@collab.net> wrote:
> On Oct 17, 2007, at 5:03 PM, Kamesh Jayachandran wrote:
>
> > I don't think if there was a discussion on this front. We support
> > 'merge source' from some other WC target(and hence can be relative
> > path), in that case we will derive the url from it. Probably we may
> > need *REPOURL*(mapping to current target) or some keywords like
> > PREV, HEAD, COMMITTED upon which we can leverage such relative urls.
>
>
> While I can't recall any discussion of this in the context of the
> merge tracking, the fact that "-g" fixes that one case is really kind
> of a coincidence -- and not entirely general, since it sometimes
> happens that you need to merge "from" several different sources, in
> which case this "remember the last one" thing won't save you from
> typing the alternate URL.
>
> There has, however, been talk from time to time about relative,
> composite local-repository parameters. For example,
>
> svn merge ./../../../branches/SOMEBRANCH
>
> would mean "find the URL for '.', apply the relative path shown, and
> use that as the URL for the merge." There are some ambiguities here
> that would have to be worked out, but nothing insurmountable. For
> example, how do you know whether that's a mixed-mode source URL, or
> actually refers to some file? Some modified syntax would probably
> work, say
>
> svn merge .@@/../../../branches/SOMEBRANCH
>
> Anyway: there has been some such discussion, but there's no great
> sense of urgency; if you think this is really important, you should
> make your case here, see if someone gets interested.
>
> As simple work-arounds, I've built myself two little helpers. One,
> called "root", prints out the repository root for the current working
> directory:
>
> svn info | sed -n '/Repository Root: /s///p'
>
> Another, called "herein", prints out the URL to the current working
> directory, but on another branch. So, for example, if I'm in ".../
> root/greek/A/B", and type "herein branches/R1", it prints ".../
> branches/R1/greek/A/B". This one's a bit too complicated to paste
> into email, but if you're interested I'd be glad to toss you a copy
> by other means.
>
> Some examples of use:
>
> (1) My Buddy Joe emails me "I fixed that bug in r2249." I think
> "hmmm, my wc's at 2319, why is it still broken for me?" I cd to the
> directory where I think the bug is and type "svn log -r2249"; svn
> says precisely nothing. "Grrr, must be in some other directory," I
> grumble. "I wonder where." Oh, never mind, I don't need to guess:
>
> svn log -vr2249 `root`
>
> (2) I see that, yeah sure, it was fixed in r2249, but on branches/B1,
> not in trunk where I want it. OK, so I need to merge that:
>
> svn merge `herein branches/B1`
>
>
>
> -==-
> Jack Repenning
> Chief Technology Officer
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> office: +1 650.228.2562
> mobile: +1 408.835.8090
> raindance: +1 877.326.2337, x844.7461
> aim: jackrepenning
> skype: jrepenning
>
>
>
>
>
I know that I have got many complaints about full URLs from some of
the developers that use the Subversion repo that I administer. I've
also done my fair share of grumbling when I'm having to work directly
with the repo. I was really excited when svnmerge introduced the
ability to use "non-ambiguous" substrings of your initialized paths.
Of course, it has it easier since you must init the destination
directory before you do anything else (which I didn't particularly
like, but what can you do). It was also a big hit with my users and
in fact almost completely rid them of having to type full URLs.
While supporting relative URLs as you have them may be useful in some
situations, I find that keeping track of all those "../"s very
difficult. I am mainly looking for a relative to the repository root
syntax. I do think that other people have similar opinions
(http://svn.haxx.se/dev/archive-2007-07/0509.shtml).
I think it would be best to mirror the svn:externals relative syntax
as much as possible for consistency. I personally only *really* care
about the "^/branches/a" syntax for root relative values. Like you
said in order to support "../" concepts some other markup would have
to be introduced.
I would think that Blair Zajac would have already done much of the
work needed to support the "^/branches/a" syntax and that putting it
into the command-line client shouldn't be too much of a problem. I
will try to look into implementing it myself, (possibly) based on
Blairs work.
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
Re: svn merge question
Posted by Jack Repenning <jr...@collab.net>.
On Oct 17, 2007, at 5:03 PM, Kamesh Jayachandran wrote:
> I don't think if there was a discussion on this front. We support
> 'merge source' from some other WC target(and hence can be relative
> path), in that case we will derive the url from it. Probably we may
> need *REPOURL*(mapping to current target) or some keywords like
> PREV, HEAD, COMMITTED upon which we can leverage such relative urls.
While I can't recall any discussion of this in the context of the
merge tracking, the fact that "-g" fixes that one case is really kind
of a coincidence -- and not entirely general, since it sometimes
happens that you need to merge "from" several different sources, in
which case this "remember the last one" thing won't save you from
typing the alternate URL.
There has, however, been talk from time to time about relative,
composite local-repository parameters. For example,
svn merge ./../../../branches/SOMEBRANCH
would mean "find the URL for '.', apply the relative path shown, and
use that as the URL for the merge." There are some ambiguities here
that would have to be worked out, but nothing insurmountable. For
example, how do you know whether that's a mixed-mode source URL, or
actually refers to some file? Some modified syntax would probably
work, say
svn merge .@@/../../../branches/SOMEBRANCH
Anyway: there has been some such discussion, but there's no great
sense of urgency; if you think this is really important, you should
make your case here, see if someone gets interested.
As simple work-arounds, I've built myself two little helpers. One,
called "root", prints out the repository root for the current working
directory:
svn info | sed -n '/Repository Root: /s///p'
Another, called "herein", prints out the URL to the current working
directory, but on another branch. So, for example, if I'm in ".../
root/greek/A/B", and type "herein branches/R1", it prints ".../
branches/R1/greek/A/B". This one's a bit too complicated to paste
into email, but if you're interested I'd be glad to toss you a copy
by other means.
Some examples of use:
(1) My Buddy Joe emails me "I fixed that bug in r2249." I think
"hmmm, my wc's at 2319, why is it still broken for me?" I cd to the
directory where I think the bug is and type "svn log -r2249"; svn
says precisely nothing. "Grrr, must be in some other directory," I
grumble. "I wonder where." Oh, never mind, I don't need to guess:
svn log -vr2249 `root`
(2) I see that, yeah sure, it was fixed in r2249, but on branches/B1,
not in trunk where I want it. OK, so I need to merge that:
svn merge `herein branches/B1`
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn merge question
Posted by Kamesh Jayachandran <ka...@collab.net>.
> I also tested this out and it worked like a charm. Still for any
> other case you would have to type out the root url to the repository
> which could add a lot of typing. You can't even use copy-n-paste from
> the 'mergeinfo' output.
>
> Was there already some discussion about allowing these kind of
> relative URLs? If Subversion did support them I guess there would
> have to be a way to disambiguate them from working copy paths. And if
> it *were* implemented, would it go into the svn client code or the
> working copy library?
>
>
I don't think if there was a discussion on this front. We support 'merge
source' from some other WC target(and hence can be relative path), in
that case we will derive the url from it. Probably we may need
*REPOURL*(mapping to current target) or some keywords like PREV, HEAD,
COMMITTED upon which we can leverage such relative urls.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn merge question
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/16/07, Kamesh Jayachandran <ka...@collab.net> wrote:
> Hi,
>
> >
> > 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?
>
> In r27191 We fixed the merge-notifications to be more clear. Can you try
> with that.
>
Yep it worked great!
> > 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?
> >
> >
>
> In fact merge source url can be optional(if invoked with -g), it
> defaults to copy source of the target if one exists or the first merge
> source from its (svn:mergeinfo).
>
I also tested this out and it worked like a charm. Still for any
other case you would have to type out the root url to the repository
which could add a lot of typing. You can't even use copy-n-paste from
the 'mergeinfo' output.
Was there already some discussion about allowing these kind of
relative URLs? If Subversion did support them I guess there would
have to be a way to disambiguate them from working copy paths. And if
it *were* implemented, would it go into the svn client code or the
working copy library?
> With regards
> Kamesh Jayachandran
>
--
"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
Re: svn merge question
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi,
>
> 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?
In r27191 We fixed the merge-notifications to be more clear. Can you try
with that.
> 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?
>
>
In fact merge source url can be optional(if invoked with -g), it
defaults to copy source of the target if one exists or the first merge
source from its (svn:mergeinfo).
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn merge question
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/13/07, Mark Phippard <ma...@gmail.com> wrote:
> On 10/13/07, Troy Curtis Jr <tr...@gmail.com> wrote:
> > On 10/13/07, Mark Phippard <ma...@gmail.com> wrote:
> > > On 10/13/07, Troy Curtis Jr <tr...@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
Re: svn merge question
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/13/07, Mark Phippard <ma...@gmail.com> wrote:
> On 10/13/07, Troy Curtis Jr <tr...@gmail.com> wrote:
> > On 10/13/07, Mark Phippard <ma...@gmail.com> wrote:
> > > On 10/13/07, Troy Curtis Jr <tr...@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
Re: svn merge question
Posted by Mark Phippard <ma...@gmail.com>.
On 10/13/07, Troy Curtis Jr <tr...@gmail.com> wrote:
> On 10/13/07, Mark Phippard <ma...@gmail.com> wrote:
> > On 10/13/07, Troy Curtis Jr <tr...@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/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn merge question
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 10/13/07, Mark Phippard <ma...@gmail.com> wrote:
> On 10/13/07, Troy Curtis Jr <tr...@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).
Thanks!
--
"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
Re: svn merge question
Posted by Mark Phippard <ma...@gmail.com>.
On 10/13/07, Troy Curtis Jr <tr...@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/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org