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
Received on Wed Jan 5 01:35:45 2005