>Olivier Sannier <email@example.com> writes:
>>>This post is to discuss exactly how they would like this implemented
>>>and managed. In particular, should the storage of working copies be
>>>defined by a property, stored in the repository for all users? Or
>>>should it be the exclusive domain of the user (and only set in the
>>>their .subversion config or .svn directory)?
>>I would prefer for it to be an option from the repository itself, that
>>could be deactivated by users. But basically, if the "admin" thinks
>>it's best for everyone to have it compressed, then he should have a
>>way to force it on new users.
>>And the way I though of it was that it would be transparent for users,
>>provided they use svn clients, not direct opening of files in
>>All in all, we agree here ;-)
>Why should the repository have anything to say about it at all?
>Size and presence of text-base is a *purely* client-side concern. If
>you have a big disk with fast I/O, you might want them all. If you
>have a small disk, or don't use the working copy much, you might not
>want them at all. Or you might only want text bases for non-binary
>All of these are concerns local to the working copy user; the
>repository administrators cannot predict these needs. So I don't see
>any point in repository configurability for this feature.
Yes, but think of SourceForge for instance. I'm an admin of some
projects over there, one of which has about 25000 files. Developers
might want to have the uncompressed text base, that's fine. But 90% of
our CVS access are done by anonymous users who do not care much for the
diffs and the development, they just want the latest code.
And clearly, the issue of disk usage is one that comes up every now and
then. Hence I would set the compression to be on by default for all, as
most users would not even know about the existence of compression.
My 2 cents
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jun 20 17:52:07 2005