You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2003/02/22 05:10:09 UTC
damned 'svn log' behavior
The behavior of 'svn log -r NNN' is really getting annoying. I don't see an
issue about this, so is it just me, or is the issue under another name?
Specifically:
$ svn info
...
Url: http://svn.collab.net/repos/svn/trunk
...
$ svn log -r 5000
------------------------------------------------------------------------
$ svn log -r 5000 http://svn.collab.net/repos/svn/
------------------------------------------------------------------------
rev 5000: cmpilato | 2003-02-20 15:20:29 -0800 (Thu, 20 Feb 2003) | 3 lines
* subversion/libsvn_fs/bdb/changes-table.c
Fix some fn-space-paren stuffs.
------------------------------------------------------------------------
So I'm sitting at the trunk, yet the -r 5000 doesn't show me that a change
was made underneath my current position. I do recall at one point, that the
log was only supposed to show changes to that particular area or below. But
it doesn't even do that now.
Even so, it still seems assinine that when I ask for the log about a
specific revision, that I don't get that data. What if the change was over
in /clients/? Better to know that, then to report nothing.
What ends up happening is that 'svn log -r NNN' tends to fail for me more
often than not, and I have to use the URL form. Ick icky. We're talking
about user workarounds here, and changing patterns of behavior from obvious
to non-obvious.
Is there a rationale for the current behavior that I'm missing?
Thanks,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Stein <gs...@lyra.org> writes:
> The behavior of 'svn log -r NNN' is really getting annoying. I don't see an
> issue about this, so is it just me, or is the issue under another name?
No, it's a FAQ :)
> Specifically:
>
> $ svn info
> ...
> Url: http://svn.collab.net/repos/svn/trunk
> ...
> $ svn log -r 5000
> ------------------------------------------------------------------------
> $ svn log -r 5000 http://svn.collab.net/repos/svn/
> ------------------------------------------------------------------------
> rev 5000: cmpilato | 2003-02-20 15:20:29 -0800 (Thu, 20 Feb 2003) | 3 lines
>
> * subversion/libsvn_fs/bdb/changes-table.c
> Fix some fn-space-paren stuffs.
>
> ------------------------------------------------------------------------
>
>
> So I'm sitting at the trunk, yet the -r 5000 doesn't show me that a change
Try using -v, that change was made on a branch.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > What ends up happening is that 'svn log -r NNN' tends to fail for me more
> > often than not, and I have to use the URL form.
>
> I have to wonder, why are you constantly asking for the log of a
> single specific revision?
I have to wonder, what kind of question is *that*? :-)
-K, who must run 'svn log -rN' at least twice a day on average
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Ben Collins <bc...@debian.org>.
> i don't particularly like the idea of having some weird special case
> for when an implicit dot is added and when it isn't. either it should
> be there for all uses of 'svn log', or none.
The whole idea of an implied option is that it changes based on
condititions. If the user wants consistency, they will make things
explicit.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins wrote:
>>>>>Ick icky. We're talking about user workarounds here, and changing
>>>>>patterns of behavior from obvious to non-obvious.
>>>>>
>>>>>
>>>>As a compromise, perhaps we can add a switch to 'svn log' which forces
>>>>it to run against the root of repository.
>>>>
>>>>
>>uh, i really don't see the point in yet another switch. just type 'svn
>>log -r FOO http://url/of/repos'. it's going to take just as long to
>>type as a long flag would, and i'm sure you're not proposing we waste a
>>short flag on something like this, right?
>>
>>
>
>Maybe it would be better to assume that -r with no path args assumes
>root of wc repo. That way Sussman's case of -r X:Y with no args still
>works so long as he adds implicit "." (or whatever paths he wants). I
>can see both sides as being correct here. The no-implicit-dot when -r is
>used seems to make the best sense (least work for both cases).
>
i don't particularly like the idea of having some weird special case
for when an implicit dot is added and when it isn't. either it should
be there for all uses of 'svn log', or none.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Ben Collins <bc...@debian.org>.
> >>>Ick icky. We're talking about user workarounds here, and changing
> >>>patterns of behavior from obvious to non-obvious.
> >>
> >>As a compromise, perhaps we can add a switch to 'svn log' which forces
> >>it to run against the root of repository.
>
> uh, i really don't see the point in yet another switch. just type 'svn
> log -r FOO http://url/of/repos'. it's going to take just as long to
> type as a long flag would, and i'm sure you're not proposing we waste a
> short flag on something like this, right?
Maybe it would be better to assume that -r with no path args assumes
root of wc repo. That way Sussman's case of -r X:Y with no args still
works so long as he adds implicit "." (or whatever paths he wants). I
can see both sides as being correct here. The no-implicit-dot when -r is
used seems to make the best sense (least work for both cases).
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Monday, February 24, 2003, at 06:32 AM, Greg Stein wrote:
> On Sat, Feb 22, 2003 at 10:00:13AM -0800, Ben Collins-Sussman wrote:
>> Greg Stein <gs...@lyra.org> writes:
>>
>>> So I'm sitting at the trunk, yet the -r 5000 doesn't show me that a
>>> change
>>> was made underneath my current position.
>>
>> It absolutely does! In revision 5000, there were no changes within
>> /trunk. Mike's commit was within /branches.
>
> Ah. I didn't realize it was in the branch (I just read the logmsg).
>
>>> Even so, it still seems assinine that when I ask for the log about a
>>> specific revision, that I don't get that data. What if the change
>>> was over
>>> in /clients/? Better to know that, then to report nothing.
>>
>> Absolutely not. If I run 'svn log -rX:Y', I only want to see
>> changes that happened within '.', not changes for the entire damn
>> repository!
>
> Not necessarily. I might also want to see those log messages, period.
> Consider the RM function and wanting to see all log messages since the
> last
> release.
>
>>> What ends up happening is that 'svn log -r NNN' tends to fail for me
>>> more
>>> often than not, and I have to use the URL form.
>>
>> I have to wonder, why are you constantly asking for the log of a
>> single specific revision?
>
> Ever see this phrase? "Fixed in rev 5020" ? Hell yah, I often want to
> see
> log messages of single revisions. IOW, I see it as a valid use case...
>
>>> Ick icky. We're talking about user workarounds here, and changing
>>> patterns of behavior from obvious to non-obvious.
>>
>> As a compromise, perhaps we can add a switch to 'svn log' which forces
>> it to run against the root of repository.
uh, i really don't see the point in yet another switch. just type 'svn
log -r FOO http://url/of/repos'. it's going to take just as long to
type as a long flag would, and i'm sure you're not proposing we waste a
short flag on something like this, right?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 22, 2003 at 10:00:13AM -0800, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > So I'm sitting at the trunk, yet the -r 5000 doesn't show me that a change
> > was made underneath my current position.
>
> It absolutely does! In revision 5000, there were no changes within
> /trunk. Mike's commit was within /branches.
Ah. I didn't realize it was in the branch (I just read the logmsg).
> > Even so, it still seems assinine that when I ask for the log about a
> > specific revision, that I don't get that data. What if the change was over
> > in /clients/? Better to know that, then to report nothing.
>
> Absolutely not. If I run 'svn log -rX:Y', I only want to see
> changes that happened within '.', not changes for the entire damn
> repository!
Not necessarily. I might also want to see those log messages, period.
Consider the RM function and wanting to see all log messages since the last
release.
> > What ends up happening is that 'svn log -r NNN' tends to fail for me more
> > often than not, and I have to use the URL form.
>
> I have to wonder, why are you constantly asking for the log of a
> single specific revision?
Ever see this phrase? "Fixed in rev 5020" ? Hell yah, I often want to see
log messages of single revisions. IOW, I see it as a valid use case...
> > Ick icky. We're talking about user workarounds here, and changing
> > patterns of behavior from obvious to non-obvious.
>
> As a compromise, perhaps we can add a switch to 'svn log' which forces
> it to run against the root of repository.
Well, I'd probably view it as "don't consider the path". To me, the notion
of "filter only to this dir" is highly non-intuitive. Any time that I
specify a revision, it means I want info about that revision, regardless of
where I happen to be sitting in my working copy.
> (FWIW, I've never been bitten by this problem. I run 'svn log' on
> specific files, or on ranges of revisions. But I never find myself
> asking for a specific revision out of thin air. I wonder why your
> use-cases are so different?)
See above...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: damned 'svn log' behavior
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> So I'm sitting at the trunk, yet the -r 5000 doesn't show me that a change
> was made underneath my current position.
It absolutely does! In revision 5000, there were no changes within
/trunk. Mike's commit was within /branches.
> Even so, it still seems assinine that when I ask for the log about a
> specific revision, that I don't get that data. What if the change was over
> in /clients/? Better to know that, then to report nothing.
Absolutely not. If I run 'svn log -rX:Y', I only want to see
changes that happened within '.', not changes for the entire damn
repository!
> What ends up happening is that 'svn log -r NNN' tends to fail for me more
> often than not, and I have to use the URL form.
I have to wonder, why are you constantly asking for the log of a
single specific revision?
> Ick icky. We're talking about user workarounds here, and changing
> patterns of behavior from obvious to non-obvious.
As a compromise, perhaps we can add a switch to 'svn log' which forces
it to run against the root of repository.
(FWIW, I've never been bitten by this problem. I run 'svn log' on
specific files, or on ranges of revisions. But I never find myself
asking for a specific revision out of thin air. I wonder why your
use-cases are so different?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org