On 11.01.2014 01:02, Ben Reser wrote:
> 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).
IMO, that's another aspect of the problem which adding any number of
command-line switches won't solve satisfactorily.
> 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.
For the last two, I already argued that they should live in a different
command. I may have suggested "svn wc" or "svn gc" or some such, in
effect, a working-copy-administration command. If we add such a thing,
then I'd agree that removing unreferences pristines should fall into the
domain of the new command.
(Do we sometimes have a tendency to hack first and think about it later?
Sure! :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-01-11 01:53:37 CET