Re: svn log hides log messages

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