On 1/10/14, 3:17 PM, Branko Čibej wrote:
> We could even not add an option, and instead only remove pristines that are
> "old enough"; e.g., touch the file timestamp every time a pristine file is
> used, and have "svn cleanup" only remove those prisitines that haven't been
> used for a certain period of time.
I think you're going to have a very hard time doing that. Users with large
files may not want any unreferenced pristines stored. Right now they do that
by running cleanup after every update/switch (kinda ugly).
Maybe we can just make the heuristics configurable. But right now we don't
have anyway to configure things per working copy. Well we sorta do with
inheritable properties, but I'm not sure if that's a good fit or not. Your
choices here are going to largely be driven by disk space and that's really a
matter for each individual client.
I was thinking of a command for pristines that let you configure the
heuristics, show how much space unreferenced vs referenced pristines were using
and possible let you just remove all or some (by age via some mechanism such as
what you suggested). In the future if we allow pristine-less working copies
this can also be the command to configure that, especially if we allow things
to be configured per path under the wc.
We've kinda gone crazy adding functions to cleanup that are entirely unrelated.
Right now it:
* finishes incomplete tasks in the wc (original purpose)
* removes write locks on the wc (original purpose)
* remove unreferenced pristines (added in 1.7 but oddly not documented in help
cleanup)
* remove unversioned files (trunk only with an option)
* remove ignored files (trunk only with an option)
I'm not sure how I feel about the last two, but even the 1.7 addition doesn't
feel like it's too late to fix since it's barely documented and seems to have
just been thrown on there. I feel like we're getting dangerously close to the
whole switch/relocate nonsense.
Received on 2014-01-11 01:02:58 CET