On Sunday, October 13, 2002, at 11:18 PM, Tom Lord wrote:
> A sort of non-sequitor: it didn't occur to me until last night, but
> getting an svn repository to host an arch repository should be utterly
> trivial -- a couple of weeks work, at most. (I can't really afford to
> do that work myself, at the moment.) It's just a matter of
> translating a small subset of FTP operations into svn operations --
> nothing more.
>
> You'd get, as a free side effect, a (good) form of distributed
> repositories, "for free". People could write pretty simple scripts
> that convert on-demand between parts of the svn tree holding arch
> global revisions and parts holding ordinary full source trees.
David Mankin
This sounds neat, but I'm pretty sure I don't really get it yet. For
those of us who don't really understand the background of arch, do you
want to give a few more paragraphs explaining what you mean? Would
this "for free" distributedness provide a local repository I can check
changes into on my laptop, and then somehow sync those changes up with
our company-wide repository when I get to work on Monday
morning?
Correct.
(Is that the same way BitKeeper works? That's about the
impression I get from their website.)
I have only a vague idea how BitKeeper works.
Arch gives you a global (cross repository) namespace for revisions.
It gives you an exchange format for exchanging change sets between
repositories and for exchanges with "dumb" (simple file system
semantics) servers.
In your scenario, you'd pick a revision on your laptop to export, some
scripts would construct and commit the necessary arch files, your
environment at work would invert the process -- checking out the arch
files from your laptop, caching them locally, applying them to your
development tree and committing those changes as a regular svn commit.
When you update the working directory at your desk, you pick up all
the changes from your laptop.
The arch scripts would (initially) see a svn repository as pretty much
a simple file system -- a "dumb" arch server. You could use, for
example, the arch mirroring commands to export the arch portion of
your svn repository to a read-only FTP site.
Because the requirements on arch back-ends are so low, you could build
a similar back-end for just about any other system (CVS, OpenCM...).
Distribution and the ability to sync up between repositories can
easily be made orthogonal to repository implementation.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 08:48:46 2002