On Dec 10, 2004, at 9:31 AM, trlists@clayst.com wrote:
> On 10 Dec 2004 Ben Collins-Sussman wrote:
>
>> Another example of this is:
>>
>> svn commit foo.c
>> svn log
>>
>> You'd think that 'svn log' would show you the commit to foo.c that you
>> just made, right? After all, that's what CVS does. But it doesn't...
>> not without running 'svn up' first. It's been the subject of much
>> debate, but it's another example of 'consistency' winning out over 'do
>> what I mean'.
>
> I'll give you that last point :-).
>
> Anyway, the item above bit me a couple of times. Why is this? What is
> svn up doing that makes the log show the commit?
>
Suppose you have a working copy, all at revision 5. You edit foo.c and
commit it, creating revision 6.
After the commit is done, your working copy of foo.c is at r6, but the
entire rest of your working copy (including the parent dir of foo.c) is
still at r5. (Most people don't realize that after *every* commit,
they have a mixed-revision working copy!)
When you run 'svn subcommand' with no arguments, it means, "run the
subcommand on a default target of CWD at its working revision". This
is the general rule.
So, immediately after you do your commit, an 'svn log' command is
actually the same as running 'svn log .@5'. In other words, "show me
all changes that ever happened within parent_dir, starting at r5, and
going backwards." And that means, of course, that r6 never shows up in
the output.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 10 17:37:33 2004