I agree with Olivier here. I hold files of several differnt types
serving many different needs in my repositories. Some of them are small
code chunks while others are large documents (we use Subversion to
control documentation as well). I wouldn't mind having the ability to
control the compression (or lack thereof) on files from the repository
side. And the user never has to know.
That said, just like other file/folder properties, I think this
functionality should be allowable at both the server and the client
side. If the repository is set for compression, but the user does not
want their local files compressed (local system performance degradation
if the files are compressed), then they should be allowed to set this in
the local config file. But it should also be configurable by file type.
And yet another thing to consider here - what program is the compression
done with? So this whole project could become a full subsection of the
config file. Something like:
[compression]
what_state_am_I_in = <on|off>
method = <what types can we use on *NIX, Win9x, Win2k,Win2003, Mic, etc>
which_files = <*, .txt, .dpr, .exe, .c, etc>
Just thoughts...
Regards,
Frank
Olivier Sannier wrote:
> kfogel@collab.net wrote:
>
>> Olivier Sannier <obones@free.fr> 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
>>> text-base.
>>> 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
>> files.
>>
>> 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
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 20 19:17:48 2005