Jamax wrote:
> So this information cannot be put in the entries files? They are being opened twice for every folder in the working copy anyway during an svn update.
>
It's technically possible to do that, but because of assumptions made
throughout the working copy code, doing that would probably be more work
than the benefit's worth. In other words, it makes more sense to work on
the new generation working copy (which, presumably, would make such a
feature easier to implement) than to try to retrofit (and debug!) it in
the current implementation. Yes, we know, our working copy
implementation produces a strong decreasing pressure gradient.
Another thing here is that, performance-wise, it would not be enough to
quickly find all file that have HEAD in svn:keywords; it's common
practice set the same svn:keywords on most files. We'd have to flag
files that actually contain that keyword (and keep the flag up to date
during version conortions). That's an order of magnitude more complex to
get right, and unless a case can be made for having such a
keyword-instance (or file-content-pattern) cache as a more generic
mechanism, i strongly doubt it's worth the effort to implement for just
$HEAD$ expansion.
Then of course there's the question whether $HEAD$ even makes sense in
general, because its value would reflect commits to unrelated branches
or even completely different projects in the same repository.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-02 00:38:46 CEST