Re: svn commit: r30009 - trunk/subversion/libsvn_wc

"Erik Huelsmann" <ehuels_at_gmail.com> writes:
> To answer your question: I think the answer is 'no': fb (file-baton)
> is about what we're being sent from the server. Replacements will be
> sent as D+A, meaning that the A code-path will be executed and 'added'
> will be TRUE. The 'added' transformation presumably leads to a new
> 'schedule-normal' file in the Working Copy.

Ah, okay. Good explanation, thank you.

> If the file wasn't added, but updated, then, if the file was
> 'replaced-with-history', we don't need to cache the working size and
> time, since those serve to detect whether the target is a committable:
> it already is. (BTW: Is receiving an update for a
> replaced-with-history file a tree conflict?)

Properly, I think that depends on the history of what it was replaced
with. Practically, I'm not sure how much it matters: the update either
will or won't textually conflict.

> In any other case, since the schedule isn't normal anyway, I don't
> think we need to cache the WC file metadata.

*nod*

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-23 18:20:13 CET