> Max Bowsher:
>> I find it hard to accept that, having decided to use a
>> version control system at all, disk space can be at such a
>> premium that it is worth sacrificing the ability to roll
>> back to previous versions.
> Yes, disk space is not the main point -- however, it hurts a
> bit if repeated releases of 3rd party's software (in our
> case) leads to repeated updates of this branch by 50 MB each
> time, with 95% stuff we do not need (but no chance to know
> it in advance). So, a simple 'overwrite feature' would be
> nice to have.
If disk space is not the main point, why would it be nice? Why is
increasing the size of the repository inherently bad?
>> I don't buy the argument about "disabling the feature of
>> using older versions" - simply not updating allows for
> I agree, however, one might see it from this view:
> (a) Isn't it the average case that in large trees people do
> not need version control for 100% of the files?
I disagree absolutely.
> (b) Wouldn't it be useful e.g. for programmers to include
> binary libraries (DLLs, whatever) into the repository (without
> version control!) to pass the latest version only to the
> others without forcing them to build the libraries?
In certain circumstances, yes, but in those circumstances, it is also
very useful - vitally important, even - to maintain an audit trail of
those binaries and allow obtaining previous versions.
> (c) Why not use the ability of file centralization and
> distribution which comes along with subversion separately
> from version management.
> I am not a subversion programmer but believe that an
> 'overwrite' feature could be realized by some kind of
It really really really isn't that simple. A property only addresses
storing a desire. The concept that files have previous versions is so
fundamental that actually implementing that desire wouldn't be a trivial
hack, it would cause major knock-on changes rippling through a large
proportion of the code.
Received on 2008-05-07 10:12:41 CEST