merging svn and arch (corrected To: line)

[Sorry -- had a bogus email address in the first To: line]

Here's some arch project's that I think would have value.

1) Write a trivial svn implementation of repositories.

   By "trivial", I mean _really_ trivial. Archive the current
   repository format in a subversion tree -- `import' the various
   .tar.gz files. In other words, there would be a svn tree that
   contains exactly what the FTP site currently contains. Adjust the
   `with-ftp' abstraction so that it can handle the svn shell client as
   a back-end.

2) work on an http-based repository protocol

   This can usefully be a read-only protocol, at first.
   Commands to support with this protocol might include `delta-patch'
   and `file-history'. In other words, support queries for arbitrary
   deltas and log file summaries.

3) write cgi-modules that expand revisions on-demand

   On the server side, a demand-driven script can check-out arch patch
   sets from the repository tree, play them out on svn working dirs,
   and commit the results back to svn. Thus, the svn database can
   expand on-demand into a library of all the revisions in the
   repository, optimized for per-file queries (such as search and
   browsing).

   If you want to get really fancy, you can optimize the use of the
   pool of working directories kept around by the cgi scripts.

Projects committed to svn using this discipline will automagically
inherit distributed revision control from arch.

There's a fourth task, that belongs more on the svn side of the wall:

4) Write a gateway tool that helps users who prefer the svn client to,
nevertheless, commit using the arch discipline for recording change
sets.

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 13 21:33:18 2002