Dylan Leigh wrote:
>I have applied for the Google Summer of Code subversion project,
>working on Optional/Compressed text-base (working copy) storage (see
>the Project Tasks page, or issues 525 and 908).
>
>
Great, thanks for the effort.
>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 ;-)
>Another approach would be to allow the user to gzip/bzip2 the
>text-base directory, or delete individual files. The client could
>then automatically uncompress the files or refetch them (with svn
>cat) before performing any operations that required those files.
>
>
That would be, I think, quite misleading. If it's transparent for users,
then I think it would be accepted much more easily.
>In terms of the actual compression or refetching; my plan is to
>handle compression first, since this would be client-side only and
>would involve the least changes. Optional storage would mean the
>client either sending the entire file or redownloading the base file
>and transmitting diffs as normal.
>
>
Agreed here too. The server should not care about the client's storage.
Send the things as usual, compress if need be on the local copy.
>Alternatively, an rsync-like algorithm could be used to reduce
>network overhead when there is no client base copy. (Of course, I'm
>not expecting to get to this stage overnight). The other options
>should still be available, as some people don't trust rsync with
>critical data.
>
>
Well, CVS transmits everything everytime, and I must admit I'm growing
used to the immediate response for doing a diff. hence, a transparent
compression (not even a hard one, 30% compression is easy to get and
fast) is IMHO the best option. Wether this is easy to implement, I do
not know, I haven't had a look at the svn client code.
Hope this helps.
Cheers
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 20 09:08:54 2005