Daniel Berlin <dan@dberlin.org> writes:
> 1. Subversion is not tied to berkeley db, the main implementation of
> the fs layer just happens to be implemented on top of berkeley.
> You could just as well replace it with one that was implemented on top of
> mysql.
>
> Thus, saying that subversion requires that everything reside in a database
> isn't right.
> 2. Subversion could be modified in less than a day to support
> replicated repositories for scalability purposes. Berkeley supports this
> stuff natively.
>
> 3. Subversion doesn't require you set up an apache server with the dav
> module to make a repository. They work locally just fine.
>
> 4. Arch is not able to better recover from server disasters because the
> files are dumb file systems. You could mirror the db just as easily,
> or, as i said above, replication could be added easily.
I would add that
"*** arch access to past revisions is faster"
seems dubious, esp given cmpilato's recent fs changes. I don't know
what data Tom based this claim on, or if it's just a guess based on
design. (Of course, the *current* live Subversion repository doesn't
contain cmpilato's improvements, so if Tom simply did a checkout of an
old revision from our repository, that might explain the claim.)
In general I think Tom's comparison is pretty fair, though it does
choose to focus on features that are Arch's strengths :-).
Heck, if Arch solves the problem, I'll happily use it. Last time I
downloaded it, it failed to check out itself (following the
instructions on the site). But the same could be said of Subversion,
depending which day you got it, so that's not in itself a big deal.
It does mean, though, that I haven't been able to play around with
Arch to compare. :-(
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006