You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by er...@swapsimple.com on 2004/12/28 00:24:52 UTC
svn log hides log messages
"svn log" has really annoying behaviour where is hides log messages
for revisions that are newer than what is currently checked out. I read
a few messages that mentions this, and it seems that this won't be changing
any time soon, but I find this behaviour horribly confusing.
Is there a configuration option that I can set to change this? I
thought there was a way to specify default args to a svn command, but
I can't seem to find it. I'd be happy if I could specify "-r HEAD" as the
default option for svn log.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by kf...@collab.net.
"Max Bowsher" <ma...@ukf.net> writes:
> Shouldn't this discussion be taking place on dev@ ?
Sorry, Max, my bad. I've reposted there; perhaps you could repost
your riposte (hah) in dev@, and the conversation can continue there?
-K
> The ideal way to do this would be to do a log of HEAD:0 pegged at BASE.
> But we can't trace efficiently trace history forward until we redesign
> the schema in 2.0.
>
> I'm -1 on just flipping the default to HEAD, since it would be
> horribly bizarre to see a different line of history being logged, if
> the name log is invoked on has been deleted and then
> replaced-with-history in HEAD, whilst your your WC is still on the
> previous historical line.
>
> +0.5 on log doing a relatedness check between URL@HEAD and URL@BASE,
> and logging HEAD:0 if the test passes.
>
> Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Max Bowsher <ma...@ukf.net>.
kfogel@collab.net wrote:
> Many users (including me) are periodically confused and/or annoyed by
> the fact that 'svn log' defaults to the working copy at BASE, instead
> of at HEAD. That is:
>
> $ svn commit -m "Commit a new revision."
> [...]
> Committed revision 245.
> $ svn log
> [... r245 is not shown, because it's too recent ...]
> $
>
> Sure, there are workarounds. You can pass "-rHEAD:0", or you can run
> log on the URL, or you can run update before log. But these are all
> inconvenient. Most people just want 'svn log' to Do The Obvious Thing
> when invoked with no arguments.
>
> IIRC, there were two reasons we chose to default to BASE:
>
> * The "Unknown Future" problem.
>
> If 'svn log' defaults to "-rHEAD:0", there is no guarantee the
> working copy's URL even exists in the repository at HEAD. We
> know it exists at BASE, of course, but who knows what may have
> happened since then? (See comment in svn_cl__log() recording
> that this was one of the objections.)
>
> * The Consistency problem.
>
> Other svn operations operate on the working copy at its base
> revision, so 'svn log' should behave consistently.
>
> The "Unknown Future" reasoning isn't terribly persuasive, IMHO. We
> shouldn't be penalizing the 99.9% common case just to avoid a very
> rare failure case. Especially when the failure case has an easy
> workaround (pass an explicit -r option).
>
> The Consistency argument isn't very persuasive either. Consistency is
> not a virtue in itself, it is only a virtue insofar as it makes
> Subversion easier to use. But in this case, the inconsistent behavior
> would actually be more intuitive. We would never see people posting
> to ask why they *are* able to see recent commits when they run log :-).
>
> Have I forgotten any arguments against making 'svn log' default to
> HEAD:0 instead of BASE:0? Are there compatibility objections? (I
> would think not, but UI changes are always a judgement call.)
>
> Would anyone object if we changed to HEAD:0 and made everyone's lives
> easier? :-)
Shouldn't this discussion be taking place on dev@ ?
The ideal way to do this would be to do a log of HEAD:0 pegged at BASE.
But we can't trace efficiently trace history forward until we redesign the
schema in 2.0.
I'm -1 on just flipping the default to HEAD, since it would be horribly
bizarre to see a different line of history being logged, if the name log is
invoked on has been deleted and then replaced-with-history in HEAD, whilst
your your WC is still on the previous historical line.
+0.5 on log doing a relatedness check between URL@HEAD and URL@BASE, and
logging HEAD:0 if the test passes.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Eric Gillespie <ep...@pretzelnet.org>.
kfogel@collab.net writes:
> Would anyone object if we changed to HEAD:0 and made everyone's lives
> easier? :-)
+1000000
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Jack O'Quin <jo...@io.com>.
Scott Palmer <sc...@2connected.org> writes:
> On Jan 4, 2005, at 9:29 AM, Jack O'Quin wrote:
>
>> Ben Collins-Sussman <su...@collab.net> writes:
>>
>> Need to habitually update after a commit.
>>
>>> True, but what can be done? The only solution is to make 'svn
>>> commit' automatically run 'svn update'. That's pretty awful.
>>
>> Naive question: why is that bad?
>>
>> Is it because the commit may have been partial? Otherwise, the WC
>> is now equivalent to the new HEAD,
>
> NOT true. WC is rev 1 another developer has committed rev 2 (but
> doesn't change the same files as you) check in WC to make rev 3 the WC
> is NOT HEAD because it doesn't have the changes from rev 2
>
>> so updating it automatically makes good sense.
>
> It makes sense because you probably want the changes from rev 2 using
> my example above.
Yes. Generally, I want to...
$ svn update
$ make
$ test
$ svn status # make sure there are no new changes
$ svn commit
$ svn update # because my WC is now at the new level
I want to avoid partial updates, because then the new HEAD would not
reflect the version I tested.
It's only the last step that seems strange when moving from CVS.
--
joq
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Scott Palmer <sc...@2connected.org>.
On Jan 4, 2005, at 9:29 AM, Jack O'Quin wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> Need to habitually update after a commit.
>
>> True, but what can be done? The only solution is to make 'svn commit'
>> automatically run 'svn update'. That's pretty awful.
>
> Naive question: why is that bad?
>
> Is it because the commit may have been partial? Otherwise, the WC is
> now equivalent to the new HEAD,
NOT true.
WC is rev 1
another developer has committed rev 2 (but doesn't change the same
files as you)
check in WC to make rev 3
the WC is NOT HEAD because it doesn't have the changes from rev 2
> so updating it automatically makes
> good sense.
It makes sense because you probably want the changes from rev 2 using
my example above.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Jack O'Quin <jo...@io.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> On Jan 3, 2005, at 5:58 PM, Vincent Lefevre wrote:
>
>> On 2005-01-02 21:48:17 -0600, kfogel@collab.net wrote:
>>> Many users (including me) are periodically confused and/or annoyed by
>>> the fact that 'svn log' defaults to the working copy at BASE, instead
>>> of at HEAD. That is:
>>>
>>> $ svn commit -m "Commit a new revision."
>>> [...]
>>> Committed revision 245.
>>> $ svn log
>>> [... r245 is not shown, because it's too recent ...]
>>> $
>>
>> IMHO, the real problem is not "svn log", but the fact that the working
>> copy is not automatically updated in some way to reflect the commit.
As a long-time CVS user, I find this confusing, too. I guess I just
need to habitually update after a commit.
> True, but what can be done? The only solution is to make 'svn commit'
> automatically run 'svn update'. That's pretty awful.
Naive question: why is that bad?
Is it because the commit may have been partial? Otherwise, the WC is
now equivalent to the new HEAD, so updating it automatically makes
good sense.
--
joq
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Scott Palmer <sc...@2connected.org>.
On Jan 3, 2005, at 8:44 PM, Ben Collins-Sussman wrote:
>
> On Jan 3, 2005, at 5:58 PM, Vincent Lefevre wrote:
>>
>> IMHO, the real problem is not "svn log", but the fact that the working
>> copy is not automatically updated in some way to reflect the commit.
>>
>
> True, but what can be done? The only solution is to make 'svn commit'
> automatically run 'svn update'. That's pretty awful.
Actually I wouldn't mind that, with a switch to suppress the update in
the odd case where that might be needed. Running 'svn up' immediately
before and after a commit is something I always do anyway. A coworker
pointed out that the one thing he likes about SourceSafe is how files
are read-only in your working copy until you check them out, even if
you aren't using locking. The benefit to him is that when he goes to
modify a file and is forced to check it out it automatically gets the
latest version at that time. Saves him from some unnecessary and
possibly complex merging, but avoids the road block that locking
introduces.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by John Szakmeister <jo...@szakmeister.net>.
Ben Collins-Sussman wrote:
>
> On Jan 3, 2005, at 5:58 PM, Vincent Lefevre wrote:
>
>> On 2005-01-02 21:48:17 -0600, kfogel@collab.net wrote:
>>
>>> Many users (including me) are periodically confused and/or
>>> annoyed by the fact that 'svn log' defaults to the working copy
>>> at BASE, instead of at HEAD. That is:
>>>
>>> $ svn commit -m "Commit a new revision." [...] Committed revision
>>> 245. $ svn log [... r245 is not shown, because it's too recent
>>> ...] $
>>
>>
>> IMHO, the real problem is not "svn log", but the fact that the
>> working copy is not automatically updated in some way to reflect
>> the commit.
>>
>
> True, but what can be done? The only solution is to make 'svn
> commit' automatically run 'svn update'. That's pretty awful.
Personally, I'd like to see another command that was the equivalent of
'commit and update' ('cu', as someone else suggested on the dev@ list).
I think it would not only hope those people who aren't really used to
mixed revision working copies, and it would help my team, especially
since we never make use of the mixed-revision features. Also, scripting
it is *a lot* more painful in Windows, and most of them use TortoiseSVN,
which is impossible to script.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: defaulting 'svn log' to HEAD revision
Posted by Dale Worley <dw...@pingtel.com>.
A big chunk of the strangeness is due to the fact that when you check in a
file, it is then at the HEAD revision, but the directory that contains it is
no longer. And that "svn log ." defaults to the BASE revision of the
directory ".", not to the BASE *of each individual file*. I don't think
people find it strange that after checking in foo.c, that bar.c is not
automatically updated to HEAD. But they do find it strange that "svn log
foo.c" will show the change they just checked in but "svn log ." will not.
Indeed, it's not very common is Subversion where a command refers to a WC
item, but then takes that item and its revision and looks at that thing in
the repository. E.g., when you "svn copy /... ...", what is copied is the
current contents of your WC.
Looking at the situation even more abstractly, there's an oddity in how "svn
log" is defined. It means "show me all the log items which modify this
revision of this directory or any other file under it", rather than "show
me, for this directory and all files under it, the log items which modify
those revisions". Those descriptions sound very similar, but for the first
one, "-rBASE" cuts off all revisions in any of the files after the
directory's BASE, whereas in the second one, "-rBASE" should clearly be
applied to each subordinate file individually. "svn log" really isn't
recursive, it only appears to be.
Dale
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Monday, January 03, 2005 8:44 PM
To: Vincent Lefevre
Cc: users@subversion.tigris.org
Subject: Re: defaulting 'svn log' to HEAD revision
On Jan 3, 2005, at 5:58 PM, Vincent Lefevre wrote:
> On 2005-01-02 21:48:17 -0600, kfogel@collab.net wrote:
>> Many users (including me) are periodically confused and/or annoyed by
>> the fact that 'svn log' defaults to the working copy at BASE, instead
>> of at HEAD. That is:
>>
>> $ svn commit -m "Commit a new revision."
>> [...]
>> Committed revision 245.
>> $ svn log
>> [... r245 is not shown, because it's too recent ...]
>> $
>
> IMHO, the real problem is not "svn log", but the fact that the working
> copy is not automatically updated in some way to reflect the commit.
>
True, but what can be done? The only solution is to make 'svn commit'
automatically run 'svn update'. That's pretty awful.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 3, 2005, at 5:58 PM, Vincent Lefevre wrote:
> On 2005-01-02 21:48:17 -0600, kfogel@collab.net wrote:
>> Many users (including me) are periodically confused and/or annoyed by
>> the fact that 'svn log' defaults to the working copy at BASE, instead
>> of at HEAD. That is:
>>
>> $ svn commit -m "Commit a new revision."
>> [...]
>> Committed revision 245.
>> $ svn log
>> [... r245 is not shown, because it's too recent ...]
>> $
>
> IMHO, the real problem is not "svn log", but the fact that the working
> copy is not automatically updated in some way to reflect the commit.
>
True, but what can be done? The only solution is to make 'svn commit'
automatically run 'svn update'. That's pretty awful.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: defaulting 'svn log' to HEAD revision
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-01-02 21:48:17 -0600, kfogel@collab.net wrote:
> Many users (including me) are periodically confused and/or annoyed by
> the fact that 'svn log' defaults to the working copy at BASE, instead
> of at HEAD. That is:
>
> $ svn commit -m "Commit a new revision."
> [...]
> Committed revision 245.
> $ svn log
> [... r245 is not shown, because it's too recent ...]
> $
IMHO, the real problem is not "svn log", but the fact that the working
copy is not automatically updated in some way to reflect the commit.
There's an even more confusing problem when, IIRC, trying to change
the svn:ignore property of the directory just after a commit: one gets
an error.
> Sure, there are workarounds. You can pass "-rHEAD:0", or you can run
> log on the URL, or you can run update before log. But these are all
> inconvenient.
There's a better workaround: use a shell alias (under Unix -- I don't
know about the other OS'es) or a wrapper.
> Would anyone object if we changed to HEAD:0 and made everyone's lives
> easier? :-)
I think that the current behavior is better for consistency, and
because a wrapper is possible.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: defaulting 'svn log' to HEAD revision
Posted by Dale Worley <dw...@pingtel.com>.
-----Original Message-----
From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net]On
Would anyone object if we changed to HEAD:0 and made everyone's lives
easier? :-)
--------------------------
I think that changing "svn log"'s behavior would not be a good idea.
My first objection is the consistency one. As it is now, "svn log" does
what it "should" do, namely give you the history of the WC file, just as
"svn diff" gives you the difference between the WC file and its base. This
is not so important when users are typing the commands, and going to a more
"do what I (most likely) mean" definition could be an improvement. But as
soon as the commands are used in scripts, "do what I mean" starts to have
unpleasant results -- in the long run, commands that are intended to be used
inside scripts tend to become more and more rigidly and consistently
defined, often at the expense of ease of use by casual users, so that they
work consistently inside scripts. (Hence the cryptic output formats of all
the little Unix shell utilities -- they aren't really designed to be used by
people, but by shell scripts.)
And the "unknown future" problem can be a lot weirder than the example you
quoted. Consider creating file main/A/B/C in rev 100, copying it to
branch-1/A/B/C in rev 200, doing a bunch of edits to both main/A/B/C and
branch-1/A/B/C in revs 201 through 299, and then in rev 300, deleting
main/A/B/C and copying branch-1/A/B/C to main/A/B/C. In a WC with BASE at
rev 299, "svn log -rHEAD:0" tells *nothing* about the changes to main/A/B/C
in revs 201 to 299 and tells all the changes to branch-1/A/B/C -- because
that's the history of main/A/B/C at rev 300.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
defaulting 'svn log' to HEAD revision
Posted by kf...@collab.net.
Many users (including me) are periodically confused and/or annoyed by
the fact that 'svn log' defaults to the working copy at BASE, instead
of at HEAD. That is:
$ svn commit -m "Commit a new revision."
[...]
Committed revision 245.
$ svn log
[... r245 is not shown, because it's too recent ...]
$
Sure, there are workarounds. You can pass "-rHEAD:0", or you can run
log on the URL, or you can run update before log. But these are all
inconvenient. Most people just want 'svn log' to Do The Obvious Thing
when invoked with no arguments.
IIRC, there were two reasons we chose to default to BASE:
* The "Unknown Future" problem.
If 'svn log' defaults to "-rHEAD:0", there is no guarantee the
working copy's URL even exists in the repository at HEAD. We
know it exists at BASE, of course, but who knows what may have
happened since then? (See comment in svn_cl__log() recording
that this was one of the objections.)
* The Consistency problem.
Other svn operations operate on the working copy at its base
revision, so 'svn log' should behave consistently.
The "Unknown Future" reasoning isn't terribly persuasive, IMHO. We
shouldn't be penalizing the 99.9% common case just to avoid a very
rare failure case. Especially when the failure case has an easy
workaround (pass an explicit -r option).
The Consistency argument isn't very persuasive either. Consistency is
not a virtue in itself, it is only a virtue insofar as it makes
Subversion easier to use. But in this case, the inconsistent behavior
would actually be more intuitive. We would never see people posting
to ask why they *are* able to see recent commits when they run log :-).
Have I forgotten any arguments against making 'svn log' default to
HEAD:0 instead of BASE:0? Are there compatibility objections? (I
would think not, but UI changes are always a judgement call.)
Would anyone object if we changed to HEAD:0 and made everyone's lives
easier? :-)
-Karl
Ben Collins-Sussman <su...@collab.net> writes:
> > "svn log" has really annoying behaviour where is hides log messages
> > for revisions that are newer than what is currently checked out. I
> > read
> > a few messages that mentions this, and it seems that this won't be
> > changing
> > any time soon, but I find this behaviour horribly confusing.
> > Is there a configuration option that I can set to change this? I
> > thought there was a way to specify default args to a svn command, but
> > I can't seem to find it. I'd be happy if I could specify "-r HEAD"
> > as the
> > default option for svn log.
>
> 'svn log', with no arguments, runs the command on the '.' directory at
> BASE revision... just like every other svn subcommand. That means
> you're asking to see the history of every commit ever made to the
> working-dir at revision BASE, then going backwards in time from there.
>
> So, if your working copy is all at revision 8, and then you commit a
> change to foo.c, the whole working is *still* at revision 8, and foo.c
> is now at revision 9. If you run 'svn log', you're asking for all
> commits that happened to r8 of the directory. That means you *won't*
> see the r9 commit you just made.
>
> The two workarounds are:
>
> 1. run 'svn log' on a URL instead of '.'
>
> 2. run 'svn up' first.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log hides log messages
Posted by er...@swapsimple.com.
On Thu, Dec 30, 2004 at 01:26:42AM -0600, Ben Collins-Sussman wrote:
> 'svn log', with no arguments, runs the command on the '.' directory at
> BASE revision... just like every other svn subcommand. That means
> you're asking to see the history of every commit ever made to the
> working-dir at revision BASE, then going backwards in time from there.
>
> So, if your working copy is all at revision 8, and then you commit a
> change to foo.c, the whole working is *still* at revision 8, and foo.c
> is now at revision 9. If you run 'svn log', you're asking for all
> commits that happened to r8 of the directory. That means you *won't*
> see the r9 commit you just made.
yes, I know how it works. You can claim that it's logically consistent
all you want, but that don't change the fact that I consider it confusing.
When I run "svn log" I'm thinking "give me the logs for the file",
not "give me the logs for some versions of the file". Given that I can't
think of any other revision control software that defines it the way that
subversion does, I feel fairly confident assuming that there are at least
a few other people that define the "log" operation the same way.
Especially if there is still a desire to have svn be similar to cvs,
the differing behavior of the log operation is, in my opinon, a major flaw.
However, I don't care to get into a religious argument over this. Since I
already have a wrapper script (to implement cvs style modules) I'll just add
this tweak there too.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 27, 2004, at 6:24 PM, erh@swapsimple.com wrote:
>
> "svn log" has really annoying behaviour where is hides log messages
> for revisions that are newer than what is currently checked out. I
> read
> a few messages that mentions this, and it seems that this won't be
> changing
> any time soon, but I find this behaviour horribly confusing.
> Is there a configuration option that I can set to change this? I
> thought there was a way to specify default args to a svn command, but
> I can't seem to find it. I'd be happy if I could specify "-r HEAD" as
> the
> default option for svn log.
>
'svn log', with no arguments, runs the command on the '.' directory at
BASE revision... just like every other svn subcommand. That means
you're asking to see the history of every commit ever made to the
working-dir at revision BASE, then going backwards in time from there.
So, if your working copy is all at revision 8, and then you commit a
change to foo.c, the whole working is *still* at revision 8, and foo.c
is now at revision 9. If you run 'svn log', you're asking for all
commits that happened to r8 of the directory. That means you *won't*
see the r9 commit you just made.
The two workarounds are:
1. run 'svn log' on a URL instead of '.'
2. run 'svn up' first.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Christopher Ness <ch...@nesser.org>.
On Tue, 2005-04-01 at 14:42 -0500, Christopher Ness wrote:
> Perhaps a solution would be to update the information for committed
> files ONLY in the working copy. This would be very fast without network
> communication to the server.
>
> For example:
> `svn commit ./Makefile -m "Added new target: clean"`
Just to clarify. I was a little sloppy with my thoughts above.
The commit would take place as normal, so obviously the client needs to
talk to the server. But updating the local working copy happens by the
client - without having to communicate with the server - based on the
outcome of the commit transaction.
Problem?
`svn update` might get confused though with these new mixed revisions.
Chris
--
Software Engineering IV,
McMaster University
PGP Public Key: http://www.nesser.org/pgp-key/
15:00:53 up 1 day, 16:44, 3 users, load average: 0.39, 0.38, 0.36
http://www.fsf.org/philosophy/no-word-attachments.html
Re: svn log hides log messages
Posted by Dominic Anello <da...@danky.com>.
On 2005-01-05 14:21:23 -0600, Shawn Harrison wrote:
----8<----
> Max Bowsher wrote elsewhere:
> >I'm -1 on just flipping the default to HEAD, since it would be
> >horribly bizarre to see a different line of history being logged, if
> >the name log is invoked on has been deleted and then
> >replaced-with-history in HEAD, whilst your your WC is still on the
> >previous historical line.
>
> I'm afraid I don't understand this. How are there different "lines of
> history" within a single branch of the repository?
I might be able to clarify this. Say your repository history looks
something like this:
r1
A /trunk
A /trunk/foo
A /trunk/bar
r2
A /branch (from /trunk:1)
r3
M /branch/foo
r4
M /trunk/foo
M /trunk/bar
r5
D /trunk/foo
r6
A /trunk/foo (from /branch/foo:3)
Now, say your WC is /trunk at r4 and you are modifying bar. When you
commit, you get a mixed WC of /trunk and /trunk/foo at r4 and /trunk/bar
at r7.
If you were to do an 'svn log foo' in your WC and log defaulted to
HEAD, you'd see r6, r3, r2, r1
Instead, the current scheme uses BASE, so you see: r4, r1
Notice that these two sets are disjoint after r1 because they are
following different lines of development. Using HEAD in this instance
would be misleading, because it wouldn't be showing you the history of
the file you actually have on disk. Using HEAD shows you the history of
the file you would get if you chose to update.
I hope this helped clarify things. I myself struggled with the BASE vs
HEAD issue at first, but in time I've come to appreciate it.
-Dominic
Re: svn log hides log messages
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> I'm not sure why maxb's argument is such a big deal. We already have
> a strategy for the scenario he describes -- we use it already in all
> of our history-tracing peg-rev stuff in svn 1.1.
>
> For example, if I run 'svn cat -r 50 foo.c@HEAD', we're already
> checking that foo.c in HEAD is the same object as foo.c in r50. If
> not, we throw an error. I don't see why 'svn log' couldn't do the
> same sanity check.
I think maxb proposed exactly that, in fact...
Want to file the issue, then? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 2:34 PM, kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>> Well, you've just presented one side of the debate that's been going
>> on forever on this list. The other side of the debate is:
>>
>> "If no target is given, then all svn subcommands default to operating
>> on '.' at its BASE revision." It's a consistency argument.
>
> Actually, as far as I know, no one is seriously making the consistency
> argument. People are making *other* arguments why we should keep it
> the way it is, for correctness reasons (see maxb's post, for example).
>
I'm not sure why maxb's argument is such a big deal. We already have a
strategy for the scenario he describes -- we use it already in all of
our history-tracing peg-rev stuff in svn 1.1.
For example, if I run 'svn cat -r 50 foo.c@HEAD', we're already
checking that foo.c in HEAD is the same object as foo.c in r50. If
not, we throw an error. I don't see why 'svn log' couldn't do the same
sanity check.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Well, you've just presented one side of the debate that's been going
> on forever on this list. The other side of the debate is:
>
> "If no target is given, then all svn subcommands default to operating
> on '.' at its BASE revision." It's a consistency argument.
Actually, as far as I know, no one is seriously making the consistency
argument. People are making *other* arguments why we should keep it
the way it is, for correctness reasons (see maxb's post, for example).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
Ben Collins-Sussman wrote [01/05/05 2:27 PM]:
>
> Well, you've just presented one side of the debate that's been going on
> forever on this list. The other side of the debate is:
> "If no target is given, then all svn subcommands default to operating on
> '.' at its BASE revision." It's a consistency argument.
> See the thread started by kfogel on this last week.
Yes, I have, thanks.
(In response to Karl's last post):
It sounds to me like you guys are trying to find a way to make it work
and still thinking through all the implications.
Thanks for listening, and for these excellent tools.
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 2:21 PM, Shawn Harrison wrote:
>
> But svn log uses the repository, not the working copy, to get the log
> for the directory. So why not use the HEAD of the directory in the
> repository itself rather than the latest version of the working copy?
> In general, why use the working copy as the point of reference for an
> operation that accesses the repository? It would seem to be more
> informative to see what has happened in the _repository_ after I last
> did svn up, not just in the wc. I already know what's happened in the
> wc.
>
Well, you've just presented one side of the debate that's been going on
forever on this list. The other side of the debate is:
"If no target is given, then all svn subcommands default to operating
on '.' at its BASE revision." It's a consistency argument.
See the thread started by kfogel on this last week.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
Shawn Harrison wrote [01/05/05 2:21 PM]:
> This would solve the vast majority of use cases.
>
That last comment was over-the-top coming from me. Sorry about that. I
guess I meant, "Sounds good to me."
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
Ben Collins-Sussman wrote [01/04/05 10:49 PM]:
>
> On Jan 4, 2005, at 7:26 PM, Jim Correia wrote:
>> The directory is a separately versioned object (with its own
>> properties, etc). You can't arbitrarily decide to call what you have
>> N+1 just because one of its children was committed.
>>
>
> Exactly. In Subversion's universe, "revision N of a directory" means 1)
> a specific list of child entries, and 2) a specific list of
> properties. As Jim said, you can't arbitrarily bump the working
> revision of a directory in a working copy just because you feel like
> it: you actually have to *have* the version of the directory.
>
Okay, that makes sense. I understand that this is how svn defines a
directory, and I understand that I don't necessarily have the latest
version when committing a new file or a changed file. (Sorry, Jim, that
I didn't understand right away.)
> So the classic example is:
>
> Say you have a working copy at r5, and commit foo.c, which creates r9.
> Certainly it's safe for the working copy to assume that its foo.c is at
> r9. But it's not safe to assume that the parent directory is at r9:
> what if somebody added or removed entries from the directory somewhere
> in r6, r7, or r8? What if somebody changed the directory's properties?
> Until you run 'svn up', it's not safe to assume that the working copy
> really has r9 of of the directory.
But svn log uses the repository, not the working copy, to get the log
for the directory. So why not use the HEAD of the directory in the
repository itself rather than the latest version of the working copy? In
general, why use the working copy as the point of reference for an
operation that accesses the repository? It would seem to be more
informative to see what has happened in the _repository_ after I last
did svn up, not just in the wc. I already know what's happened in the wc.
Max Bowsher wrote elsewhere:
> I'm -1 on just flipping the default to HEAD, since it would be
> horribly bizarre to see a different line of history being logged, if
> the name log is invoked on has been deleted and then
> replaced-with-history in HEAD, whilst your your WC is still on the
> previous historical line.
I'm afraid I don't understand this. How are there different "lines of
history" within a single branch of the repository?
> +0.5 on log doing a relatedness check between URL@HEAD and URL@BASE,
> and logging HEAD:0 if the test passes.
This would solve the vast majority of use cases.
Shawn Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On Jan 5, 2005, at 6:28 AM, Simon Comeau Martel wrote:
>
>>> Say you have a working copy at r5, and commit foo.c, which creates
>>> r9. Certainly it's safe for the working copy to assume that its
>>> foo.c is at r9. But it's not safe to assume that the parent
>>> directory is at r9: what if somebody added or removed entries from
>>> the directory somewhere in r6, r7, or r8? What if somebody changed
>>> the directory's properties? Until you run 'svn up', it's not safe to
>>> assume that the working copy really has r9 of of the directory.
>>
>> But if you have a working copy at r5 and your commit r6, (ie: a bump of
>> exacly 1), wouldn't it be safe to assume that your entire working copy
>> is at r6, without an update?
>>
>
> Absolutely. But this is an incredibly rare and contrived case. Most
> of the time, you have a working copy made out of many mixed revisions,
> and 'svn commit' creates a new HEAD revision that is more than 1
> greater than the greatest revnum in the working copy. If you'd like to
> write optimization code for this teeny-tiny edge-case, it's certainly
> doable. I doubt it will make much difference.
... and we might well deem the extra complexity of an unnecessary edge case
to be a greater burden to maintainability than it is a benefit.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 5, 2005, at 6:28 AM, Simon Comeau Martel wrote:
>> Say you have a working copy at r5, and commit foo.c, which creates
>> r9. Certainly it's safe for the working copy to assume that its
>> foo.c is at r9. But it's not safe to assume that the parent
>> directory is at r9: what if somebody added or removed entries from
>> the directory somewhere in r6, r7, or r8? What if somebody changed
>> the directory's properties? Until you run 'svn up', it's not safe to
>> assume that the working copy really has r9 of of the directory.
>
> But if you have a working copy at r5 and your commit r6, (ie: a bump of
> exacly 1), wouldn't it be safe to assume that your entire working copy
> is at r6, without an update?
>
Absolutely. But this is an incredibly rare and contrived case. Most
of the time, you have a working copy made out of many mixed revisions,
and 'svn commit' creates a new HEAD revision that is more than 1
greater than the greatest revnum in the working copy. If you'd like to
write optimization code for this teeny-tiny edge-case, it's certainly
doable. I doubt it will make much difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Simon Comeau Martel <ma...@videotron.ca>.
> Say you have a working copy at r5, and commit foo.c, which creates r9.
> Certainly it's safe for the working copy to assume that its foo.c is at
> r9. But it's not safe to assume that the parent directory is at r9:
> what if somebody added or removed entries from the directory somewhere
> in r6, r7, or r8? What if somebody changed the directory's properties?
> Until you run 'svn up', it's not safe to assume that the working copy
> really has r9 of of the directory.
But if you have a working copy at r5 and your commit r6, (ie: a bump of
exacly 1), wouldn't it be safe to assume that your entire working copy
is at r6, without an update?
--
Simon Comeau Martel
martelsc@videotron.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 4, 2005, at 7:26 PM, Jim Correia wrote:
> On Jan 4, 2005, at 8:17 PM, Shawn Harrison wrote:
>
>> To my thinking, the version number of the directory itself should be
>> the same as the latest version of any file within it. When foo.c is
>> committed, there is also an implicit change to the parent dir
>> (namely, what it contains). So the parent dir should also have the
>> later revision number, all the way back up the parent hierarchy.
>
> The directory is a separately versioned object (with its own
> properties, etc). You can't arbitrarily decide to call what you have
> N+1 just because one of its children was committed.
>
Exactly. In Subversion's universe, "revision N of a directory" means
1) a specific list of child entries, and 2) a specific list of
properties. As Jim said, you can't arbitrarily bump the working
revision of a directory in a working copy just because you feel like
it: you actually have to *have* the version of the directory.
So the classic example is:
Say you have a working copy at r5, and commit foo.c, which creates r9.
Certainly it's safe for the working copy to assume that its foo.c is at
r9. But it's not safe to assume that the parent directory is at r9:
what if somebody added or removed entries from the directory somewhere
in r6, r7, or r8? What if somebody changed the directory's properties?
Until you run 'svn up', it's not safe to assume that the working copy
really has r9 of of the directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Jim Correia <ji...@pobox.com>.
On Jan 4, 2005, at 8:17 PM, Shawn Harrison wrote:
> To my thinking, the version number of the directory itself should be
> the same as the latest version of any file within it. When foo.c is
> committed, there is also an implicit change to the parent dir (namely,
> what it contains). So the parent dir should also have the later
> revision number, all the way back up the parent hierarchy.
The directory is a separately versioned object (with its own
properties, etc). You can't arbitrarily decide to call what you have
N+1 just because one of its children was committed.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Shawn Harrison <ha...@tbc.net>.
The following was posted to users, but my question seems more like a
dev@ issue.
Ben Collins-Sussman wrote [01/04/05 6:33 PM]:
>> I assumed [ass outta you and me] the reason the `log` command held back
>> the new revision info was that the working copy didn't have the required
>> metadata until and `update` command was issued.
>>
>>
>
> (Everytime I explain this on the list, I swear under my breath that
> there's no FAQ for this in the book or website. But now there's a
> possibility the behavior may change, so I'm not going to write the FAQ.
> Instead, I'm going to repeat it all again, because I'm too lazy to look
> up my last explanation in the mail archives. :-) )
>
> If you have a working copy at r5, then 'svn commit foo.c', then foo.c is
> at r6, everything else still at r5. We've already established that.
>
> When you run 'svn log' with no arguments, it assumes a target of '.'
> just like every other command -- that is, that the 'target' of the
> command is the parent directory of foo.c. You're asking the server to
> "tell me all commits that ever happened to (or within) the parent
> directory." And because no peg-revision was specified, it assumes you
> want to know all commits that ever affected the parent directory *at its
> base revision*, which is 5. So the server happily digs up revision 5
> of the parent directory, and starts searching backwards through
> commits: r5, r4, r3, r2... and so on, sending only commit logs that
> affected that directory.
>
> If you had run 'svn update' first, to bring the entire working copy to
> r6, then 'svn log' would ask for the history of '.' at r6, and therefore
> you would see the commit you just made to foo.c.
>
I understand that the reason "svn log ." doesn't show the just-completed
change is so that svn log works like everything else, on the current
revision of the directory. Okay.
To my thinking, the version number of the directory itself should be the
same as the latest version of any file within it. When foo.c is
committed, there is also an implicit change to the parent dir (namely,
what it contains). So the parent dir should also have the later revision
number, all the way back up the parent hierarchy.
This behavior seems to me to be the complement of "svn ci .", in which
the directory is brought to a new revision as well as all modified files
within it.
Anyway, I'd be interested to know why what I've described is _not_ what
happens, because no doubt there's a very good design reason.
Thanks,
Shawn Harrison
--
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 4, 2005, at 3:54 PM, Christopher Ness wrote:
> On Tue, 2005-04-01 at 14:13 -0600, Ben Collins-Sussman wrote:
>> On Jan 4, 2005, at 1:42 PM, Christopher Ness wrote:
>>>
>>> For example:
>>> `svn commit ./Makefile -m "Added new target: clean"`
>>>
>>> Ends up modifying the data in .svn (the working copy) to update only
>>> the
>>> entr{y,ies} for files affected by the commit. Therefore you now have
>>> the data in the working copy about the recent commit, but no new
>>> information is available about files which have not been committed.
>>> You
>>> still have a mixed working copy but you have information in your
>>> working
>>> copy about your last commit.
>>
>> This is already how 'svn commit' works.
>>
>> If your working copy is all at r5, and 'svn commit' discovers and
>> commits foo.c, then after the commit:
>>
>> foo.c is at r6
>> the whole rest of the working copy is at r5
>>
>> In other words, you have a mixed-rev working copy after *every*
>> commit.
>> Only 'svn update' brings the whole working copy to the same
>> revision.
>
> I don't know how the working copy stores information. I'll admit that
> right now so I may have some misplaced ideas.
>
> `status -v` knows that foo.c is at r6 and the rest of the working copy
> is at r5 after the commit you described.
>
> My question is this: Is the log information [and other metadata] for
> (foo.c@r6) available in the working copy data structures after the
> commit?
No, the log messages for a whole project is a tremendous amount of
information, and not cached in a working copy. 'svn log' always asks
the server for the history; the server decides which commit logs are
relevant and streams them over the network.
>
> I assumed [ass outta you and me] the reason the `log` command held back
> the new revision info was that the working copy didn't have the
> required
> metadata until and `update` command was issued.
>
>
(Everytime I explain this on the list, I swear under my breath that
there's no FAQ for this in the book or website. But now there's a
possibility the behavior may change, so I'm not going to write the FAQ.
Instead, I'm going to repeat it all again, because I'm too lazy to
look up my last explanation in the mail archives. :-) )
If you have a working copy at r5, then 'svn commit foo.c', then foo.c
is at r6, everything else still at r5. We've already established that.
When you run 'svn log' with no arguments, it assumes a target of '.'
just like every other command -- that is, that the 'target' of the
command is the parent directory of foo.c. You're asking the server to
"tell me all commits that ever happened to (or within) the parent
directory." And because no peg-revision was specified, it assumes you
want to know all commits that ever affected the parent directory *at
its base revision*, which is 5. So the server happily digs up
revision 5 of the parent directory, and starts searching backwards
through commits: r5, r4, r3, r2... and so on, sending only commit logs
that affected that directory.
If you had run 'svn update' first, to bring the entire working copy to
r6, then 'svn log' would ask for the history of '.' at r6, and
therefore you would see the commit you just made to foo.c.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Christopher Ness <ch...@nesser.org>.
On Tue, 2005-04-01 at 14:13 -0600, Ben Collins-Sussman wrote:
> On Jan 4, 2005, at 1:42 PM, Christopher Ness wrote:
> >
> > For example:
> > `svn commit ./Makefile -m "Added new target: clean"`
> >
> > Ends up modifying the data in .svn (the working copy) to update only
> > the
> > entr{y,ies} for files affected by the commit. Therefore you now have
> > the data in the working copy about the recent commit, but no new
> > information is available about files which have not been committed.
> > You
> > still have a mixed working copy but you have information in your
> > working
> > copy about your last commit.
>
> This is already how 'svn commit' works.
>
> If your working copy is all at r5, and 'svn commit' discovers and
> commits foo.c, then after the commit:
>
> foo.c is at r6
> the whole rest of the working copy is at r5
>
> In other words, you have a mixed-rev working copy after *every* commit.
> Only 'svn update' brings the whole working copy to the same revision.
I don't know how the working copy stores information. I'll admit that
right now so I may have some misplaced ideas.
`status -v` knows that foo.c is at r6 and the rest of the working copy
is at r5 after the commit you described.
My question is this: Is the log information [and other metadata] for
(foo.c@r6) available in the working copy data structures after the
commit?
I assumed [ass outta you and me] the reason the `log` command held back
the new revision info was that the working copy didn't have the required
metadata until and `update` command was issued.
Chris
--
Software Engineering IV,
McMaster University
PGP Public Key: http://www.nesser.org/pgp-key/
16:45:43 up 1 day, 18:29, 3 users, load average: 0.27, 0.08, 0.02
http://www.fsf.org/philosophy/no-word-attachments.html
Re: svn log hides log messages
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 4, 2005, at 1:42 PM, Christopher Ness wrote:
>
> For example:
> `svn commit ./Makefile -m "Added new target: clean"`
>
> Ends up modifying the data in .svn (the working copy) to update only
> the
> entr{y,ies} for files affected by the commit. Therefore you now have
> the data in the working copy about the recent commit, but no new
> information is available about files which have not been committed.
> You
> still have a mixed working copy but you have information in your
> working
> copy about your last commit.
>
> Make sense? Or am I just blowing steam?
>
This is already how 'svn commit' works.
If your working copy is all at r5, and 'svn commit' discovers and
commits foo.c, then after the commit:
foo.c is at r6
the whole rest of the working copy is at r5
In other words, you have a mixed-rev working copy after *every* commit.
Only 'svn update' brings the whole working copy to the same revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Christopher Ness <ch...@nesser.org>.
On Wed, 2004-29-12 at 13:39 -0600, erh@swapsimple.com wrote:
> On Wed, Dec 29, 2004 at 03:21:37AM -0500, Jim Correia wrote:
> > On Dec 27, 2004, at 7:24 PM, erh@swapsimple.com wrote:
> > > "svn log" has really annoying behaviour where is hides log messages
> > >for revisions that are newer than what is currently checked out. I
> > >read
> > >a few messages that mentions this, and it seems that this won't be
> > >changing
> > >any time soon, but I find this behaviour horribly confusing.
8< snip 8<
> > svn log -r HEAD:0 file.ext
>
> oh, yeah, of course.
> hmm... I guess I'll just write a wrapper script to add the
> default. ugh.
Well, it doesn't take much to realize that some commands take place on
the server, and some on the working copy.
Perhaps a solution would be to update the information for committed
files ONLY in the working copy. This would be very fast without network
communication to the server.
For example:
`svn commit ./Makefile -m "Added new target: clean"`
Ends up modifying the data in .svn (the working copy) to update only the
entr{y,ies} for files affected by the commit. Therefore you now have
the data in the working copy about the recent commit, but no new
information is available about files which have not been committed. You
still have a mixed working copy but you have information in your working
copy about your last commit.
Make sense? Or am I just blowing steam?
Cheers,
Chris
--
Software Engineering IV,
McMaster University
PGP Public Key: http://www.nesser.org/pgp-key/
14:31:59 up 1 day, 16:15, 2 users, load average: 0.23, 0.28, 0.31
http://www.fsf.org/philosophy/no-word-attachments.html
Re: svn log hides log messages
Posted by er...@swapsimple.com.
On Wed, Dec 29, 2004 at 03:21:37AM -0500, Jim Correia wrote:
> On Dec 27, 2004, at 7:24 PM, erh@swapsimple.com wrote:
> > "svn log" has really annoying behaviour where is hides log messages
> >for revisions that are newer than what is currently checked out. I
> >read
> >a few messages that mentions this, and it seems that this won't be
> >changing
> >any time soon, but I find this behaviour horribly confusing.
> > Is there a configuration option that I can set to change this? I
> >thought there was a way to specify default args to a svn command, but
> >I can't seem to find it. I'd be happy if I could specify "-r HEAD" as
> >the
> >default option for svn log.
>
> I don't think you can specify a default, but even if you could, "-r
> HEAD" will give you the log entry for the head revision only. What you
> need it is
>
> svn log -r HEAD:0 file.ext
oh, yeah, of course.
hmm... I guess I'll just write a wrapper script to add the
default. ugh.
thanks
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log hides log messages
Posted by Jim Correia <ji...@pobox.com>.
On Dec 27, 2004, at 7:24 PM, erh@swapsimple.com wrote:
> "svn log" has really annoying behaviour where is hides log messages
> for revisions that are newer than what is currently checked out. I
> read
> a few messages that mentions this, and it seems that this won't be
> changing
> any time soon, but I find this behaviour horribly confusing.
> Is there a configuration option that I can set to change this? I
> thought there was a way to specify default args to a svn command, but
> I can't seem to find it. I'd be happy if I could specify "-r HEAD" as
> the
> default option for svn log.
I don't think you can specify a default, but even if you could, "-r
HEAD" will give you the log entry for the head revision only. What you
need it is
svn log -r HEAD:0 file.ext
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn log hides log messages
Posted by Dale Worley <dw...@pingtel.com>.
There's no particularly good way to fix this without violating the rule that
commands applied to a WC file implicitly refer to that file's current rev.
If you want to get away from that, you can use "svn log http://...".
What I'd like to see is "svn info http://...", so you could directly fetch
the current rev of the object, etc.
Dale
-----Original Message-----
From: erh@swapsimple.com [mailto:erh@swapsimple.com]
"svn log" has really annoying behaviour where is hides log messages
for revisions that are newer than what is currently checked out. I read
a few messages that mentions this, and it seems that this won't be changing
any time soon, but I find this behaviour horribly confusing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org