-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 05 February 2002 17:17, Karl wrote:
> This is technically true, but that's a pretty big change. I think
> it's quite fair of Tom to simply say "Subversion uses Berkeley DB for
> its repository" and leave it at that. Any system can be changed,
> including Arch; the SQL backend claim amounts to saying "Subversion
> has clean internal interfaces", which for all we know, Arch does too.
I suppose I was thinking (a) subversion was specifically /designed/ to have
pluggable backends, and (b) there's a strong faction of SQLers in the group.
Adding backends isn't a priority, but I got the impression that it was pretty
high on the list for post-1.0.
> > of a file or directory. Arch stores the entire file multiple times.</li>
>
> If this is true about Arch, I'm surprised. Are you sure Arch isn't
> also doing diffy storage?
No, I'm not sure. That's part of the reason I posted it for review, before I
submitted it. However, if Arch /is/ doing diffy storage, than some of the
other statements are misleading. For example, the claim is made that you can
use other, normal tools on the repository, like grep, diff, etc. While
technically true, I can't imagine how it could possibly be useful. There is
no server in Arch, per se. The protocol is FTP. Who's doing the diffs? The
client. Imagine what the server side must look like to support versioning.
> > (Caveat: this code isn't currently working,
> > but should be by the 1.0 release).</li>
>
> Nah, cross-repository operations are probably post-1.0.
Really? I thought, with the recent discussions on the list, that the code
was already there, just not working. Should I take the entire comment out?
> I wouldn't be so sure about that claim that there's no advantage to
> Arch's model. Everyone I ever talked to who actually used such a
> system on a daily basis (Bitkeeper) preferred it to the CVS
> centralized-repository style. That's not a huge number of people, but
> it was enough to make me think I might prefer it myself, if I ever got
> a chance to use it for a while.
Uh, yeah, well... I don't want to dismiss Arch, but I'd say that this is more
a failing of CVS than an achievement of any other system. CVS was/is
/painful/ to use, mostly (IMO) due to the lack of directory versioning.
Almost anything is better.
> > <i>arch is better able to recover from server disasters</i>
> > The argument was that, because arch is a dumb FS,
> > it is easily mirrored. The implication is that
> > databases aren't easily mirrored. BDB is just
> > as easily mirrored, and most other databases are
> > easily <b>replicated</b>.
>
> Good call, and thanks to Daniel Berlin for pointing it out too.
Yeah, I see he beat me to it.
> Greg Stein also mentioned a bunch of advantages, search for his recent
> post to gather them up, if you are so inclined...
Yeah. I didn't want to write a "vs." document; I felt it was important to
post a response quickly to /., before hordes of people got the wrong
impression about Subversion. I specifically said I wasn't out to compare
(from the other POV) SVN to Arch, but to address mistakes in Tom's comparison.
I don't know enough about Arch to do a fair comparison.
- --
|.. I was wrong once; I thought I made a mistake.
<|>
/|\
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8YI19P0KxygnleI8RAipAAJ9inKw/Nk+kWMnd4o1dM6CTpqYw5QCfcOJp
RLsFWWYlAkypM0W/Cz0WR78=
=8FDF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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