On Wed, Dec 11, 2013 at 8:26 PM, Ben Reser <b...@reser.org> wrote:
>
> Absolutely, the answer here isn't a one size fits all. Nobody is objecting to
> the idea of allowing this. The problem is that the code is not designed to
> allow this and it's a ton of work to change that. I can think of a good 10
> other things that would require the same level of effort that would improve
> things for a lot more people
>
> Once you no longer need a pristine there are a lot of potential scenarios that
> require different behaviors. So it's not even a simple matter of just
> changing
> the working copy library to support pristines not existing. It becomes
> thinking about how to deal with these scenarios (not that all of them need to
> be implemented immediately, but you probably want to not pigeon hole yourself
> into an implementation that doesn't support them).
I guess I don't understand why it couldn't be as simple as having the
library get a pristine copy on demand if some operation needs it.
Isn't there already a recovery procedure for a missing pristine file?
And then make saving it optional.
As a case in point, consider the accumulation of cruft on a typical
jenkins build server where a large set of projects are built and
rarely removed - you have to allow much more disk space to each build
slave to accommodate the pristine files that don't have a whole lot of
use.
--
Les Mikesell
lesmikes...@gmail.com
