John, I think you just described SVK
> -----Original Message-----
> From: John Peacock [mailto:john.peacock_at_havurah-software.org]
> Sent: Wednesday, April 23, 2008 9:56 AM
> To: David Glasser
> Cc: Subversion Developers
> Subject: Re: Why rewrite the Subversion working copy?
>
> David Glasser wrote:
> > For the lowest layer, I've started implementing a prototype in Python
> > of a low-level Subversion metadata store, with full unit tests and
> all
> > that jazz. Currently I've designed the API for a refcounted
> blobstore
> > and am working on tree and treestore abstractions. I'll put it
> > somewhere (http://svn.collab.net/repos/svn/experimental/svnws? gvn
> > repository? whatever) sometime soon, once I've got a little more
> > implemented. The key goal here is to create a *non-brittle* working
> > copy, where we don't have to be scared that typing "svn switch" with
> > the wrong URL will corrupt the working copy irretrievably.
> Efficiency
> > is nice too. (Hopefully, while the code itself will probably need to
> > be backported to C, the tests might end up being executable against
> > the "real" code.)
>
> I've been actually wondering for a while why Subversion couldn't just
> use the existing server repo code for the client meta-data. A mini
> local repo of configurable depth (up to and including a full mirror).
> Updates would use svnsync-like operations to update the local repo
> before updating the working copy itself. Revs outside of the
> configured
> window would get purged automatically (or a config option could let
> them
> just build up over time). A zero-depth local repo would require server
> access for all operations and would still have just the properties and
> checksums locally (equivalent to all of the file contents forced to
> zero
> size), so enormous checkouts would not be 2x as large any longer.
>
> All operations would be performed against the local "repo" when
> possible
> (i.e. if you are disconnected, commits go against the local repo and
> are
> resolved when reconnected) and against the server when required (you
> only have the last 10 revs locally, so asking for a full history
> requires a server roundtrip, just like it does now).
>
> Each local metadata repo would effectively be a branch of the main repo
> (so multiple remote repos would have multiple local branch/mirrors),
> and
> the existing merge-tracking code can be reused to facilitate conflict
> resolution caused by offline operations.
>
> I've got some handwritten notes at home about some of the other
> implications of this, but my home machine is in between operating
> systems at the moment, so I've been very much out of the loop for a
> while. Is this something that I should try and flesh out into a more
> robust proposal???
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-23 19:06:18 CEST