-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I was going to post this followup. Does anybody want to proof it for glaring
inaccuracies? I've left the HTML formatting in, 'cause it is easier for me.
Thanks.
=== BEGIN
I'm not addressing Subversion vs. Arch, but rather
Tom's evaluation of Subversion, which isn't entirely accurate.
I'd also like to say, up front, to the Anonymous
poster who asked:
<p>
<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.
<p>
Now, on to Tom's comparison to Subversion. Caveat:
I am <b>not</b> a Subversion guru. I lurk in the
developer mailing list, and I use Subversion myself.
Therefore, I may make mistakes about details, but
I'm fairly certain I won't provide completely bogus
information.
</p>
I'm not going to quote whole sections; just enough for
context.
<ol>
<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>
<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. 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>
<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>
<li>
</ol>
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>.
=== END
- --
|.. "Macintosh... Proof that a Person can use a Computer all day and
<|> still not know ANYTHING about computers."
/|\ -- anon
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8YH6cP0KxygnleI8RAlt4AJ4z/J+gg8/+s0XCUH5d8Oes9PXlOACfXuUQ
kqhrjDjCXYvp4YmdpcKVuHU=
=SMsI
-----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