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. [email protected]
