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).
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)?
At the moment I'm thinking the best solution would be to use a
property which can be overridden by a user configured value in
.svn/entries (or similar). This has the advantage that when you add
something huge to the repository the storage type only needs to be
set once; but individual users can override this.
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.
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.
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.
Thanks in advance for any feedback,
--
Dylan Leigh - http://yallara.cs.rmit.edu.au/~dleigh/
- application/pgp-signature attachment: stored
Received on Mon Jun 20 06:22:03 2005