Sean Russell <ser@germane-software.com> writes:
> <i>Anyone know a good system of incoroprating source control with a
> databases? Oracle and Postgres would do.</i>
> <p>
> Subversion does. The backend it <i>currently</i>
> uses is Berkeley DB, but the backend is pluggable.
> After version 1.0 comes out, expect to see a backend
> for one of the SQL databases pop up.
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.
> <li><i>Smart Servers vs. Smart Clients.</i> Subversion
> clients are also smart, although perhaps not as smart
> as Arch. Diffs travel in both directions,
> so a minimum of network traffic is used. Many Subversion
> operations (status, diffs against the last revision, etc)
> are client-side opereations. In fact, this makes
> Subversion faster than Arch for updates and commits,
> because Arch passes the entire file that has changed,
> not just the diffs. Of course, you still
> need the server to be running to commit.</li>
+1 nicely said
> <li><i>Trees in a Database vs. Trees in a File Systems</i>
> This is misleading; again, the Subversion back-end
> is pluggable. You *can* get stuff out of the Subversion
> database with the standard BDB tools, so Subversion
> isn't required. Also, because Subversion is based
> on WebDAV, access to the database through a web
> server is a freebee.
This is a big point, could be emphasized even more?
We have repository browsing _today_, for free. That's pretty
amazing. :-)
> Ultimately, however, the end
> result of using a filesystem rather than a database
> is that Arch repositories will quickly become enormous.
> Subversion only stores the differences between two versions
> 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?
> <li><i>Centralized Control vs. Open Source Best Practices</i>
> In practical application, there is no advantage to the ARCH system
> over Subversion. Subversion allows per-file/directory sourcing,
> so you could create a project that includes sources from any number
> of different repositories.
> (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.
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.
> These are simple mistakes. There was one statement that
> I found to be just plain wrong:
> <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.
Greg Stein also mentioned a bunch of advantages, search for his recent
post to gather them up, if you are so inclined...
-Karl
---------------------------------------------------------------------
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