Replying to the last three posts (Nathan, Karl, Johan).
Nathan wrote:
> The pristine for a given file is not fetched until the file is
> modified and an
> operation pertaining to it requires the pristine.
That's basically how the 'pristines-on-demand' branch is working.
However, the present implementation fetches ('hydrates') pristines for
every file within the whole subtree the operation targets. That is
pessimistic: the operation may not actually touch all these files if
limited in any way such as by depth filtering. I'll follow up with a
separate report on that.
> Once fetched, the pristine remains present until the file becomes unmodified
> through either 'commit' or 'revert'.
More precisely, the pristine remains until the file is once again
detected to be unmodified, which could happen by any means including
'commit' or 'revert' or being returned to its previous state by the user
outside of Subversion's control.
> [...] it occurred to me that if the file is deleted, the
> pristine (if present) should be deleted as well. (Potential caveat: if
> the file
> is modified, subsequently marked for deletion with '--keep-local', and
> subsequently the user runs 'svn revert', the expected result is to
> restore the original contents as they appear in BASE.)
The expected result for reverting any file marked as "deleted", no
matter whether it is present on disk, modified or not, is to return it
to pristine state.
I suppose your instinct is to not "waste space" once the user has
decided the file is no longer wanted, especially if it's a huge file and
the pristine isn't going to be useful for diffs etc.
That all makes sense once we commit the delete, but until then it's
considered a temporary working state that we might want to revert.
Because this file is in a state of local modification (in the general
sense that includes delete), I think the pristine should be kept, in
line with the simple and general policy that we should keep pristines
around for all files in a locally modified state. I understand we could
treat the "deleted" state specially, but not sure we should.
>From what I understand so far of the current state of implementation, a
delete operation will first "hydrate" the textbase storage by copying
the file from working storage if it's present and unmodified, before
deleting it; and otherwise will mark it as "pristine needed" to be
fetched later on demand.
Karl wrote:
> And it only fetches pristine for commands that absolutely need
> pristine, I assume? (I think you said earlier that it does not
> fetch for 'commit'.)
Only for commands that need them, but, as mentioned above,
pesimistically for every file that the command *possibly* pertains to.
I'll follow up on that.
It will not fetch for 'commit' once I commit Evgeny's tiny patch to make
it so.
>> The only case in which [that] might be unsatisfactory is [...]
>> - there is a subset of files on which the user needs to work [...]
>> often enough that fetching their pristines "on demand" is a problem;
>> [...]
>> It is not one of the cases driving this [...]
>
> Well, that case is almost exactly our use case at my company :-),
> except that I think fetching pristines on demand will be fine.
Well, that's the crucial difference: in your case, fetching some
pristines on demand sometimes is not a problem, so this solution works.
Johan wrote:
> Just as another data point, at my company we have a slightly different
> use case where this feature would be great (I think), and where a
> simple per-WC-yes/no switch would work fine. In this case, we'd
> probably also want a "system-wide runtime config area default".
>
> The use case: [...] "I don't need 99.9% of
> those pristines most of the time, and it's blazingly fast to get them
> when needed".
>
> Ideally, after pristines-on-demand become possible, I'd do the following:
> - Set a system-wide flag to make pristines-on-demand the default for
> new WC's.
Makes sense.
> - Run a script to "convert" all existing working copies to
> pristines-on-demand (setting the per-WC flag).
Agreed, we need to ensure there is a way to do this.
> - Run a script to "vacuum-pristines" those converted working copies.
Agreed, if the previous step doesn't do it.
(In the current implementation, 'svn upgrade' does this.)
> - Receive chocolates from our sysadmins (probably not, but I can try).
Hehe.
> (BTW: a lot of those working copies are similar, so a feature to have
> a "shared pristine store" would also help [...])
Agreed, that's an alternative with different pros and cons, that would
have approximately the same overall benefit in your case.
- Julian
