-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For better or worse, this is what I submitted to Slashdot. I tried to
address all of the comments that flew around, including cleaning out my
mistakes that Tom pointed out, and I tried to give credit to commenters from
the dev list. I didn't credit everybody who commented; just the people I
blatently cut-&-pasted from. Sorry about that. I wanted to get the rebuttle
submitted before the article was too stale.
Note: I /tried/ to avoid the whole "Subversion is better than Arch" thing,
but wasn't completely successful. /Nowhere/ did I say that there was no
merit to Arch.
Sorry again for the formatting. I'm too lazy to pretty it up for you folks.
=== BEGIN
I'm not addressing Subversion vs. Arch, but rather
Tom's evaluation of Subversion, which isn't entirely accurate.
<p>
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. I got some reviews on this post from the
Subversion dev list, including some comments from Tom,
but any mistakes in here are my own, and they're copyrighted
mistakes, dammit.
</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 purely client-side opereations.</li>
<li><i>Trees in a Database vs. Trees in a File Systems</i>
This is misleading. 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; also, Subversion is very Windows
friendly, from many points of view, which should help its
adoption in a corporate setting.
Subversion only stores the differences between two versions
of a file or directory, which is space efficient. The advantage
to being able to access a filesystem-based repository of diffs
is arguable.</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. (This code is not currently working
in Subversion.)</li>
<li>
</ol>
These are simple mistakes. There is also one statement that
is flat 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>.
<p>
Other comments pointed out were:
<ul>
<li>Subversion does not require Apache. It works over a local
filesystem just fine. If you want network access, you need
Apache.</li>
<li>Subversion has all of the strengths of Apache. You therefore
get Apache access control (well defined and understood), SSL,
client and server certificates, and interoperability with other
WebDAV clients, among other things.</li>
<li>With Subversion, you have both client side and server side hooks,
as well as smart diffs.</li>
<li>Arch has both revision libraries and repositories. The comparison
document doesn't differentiate between them. In some cases, the
comparisons made aren't meaningful. Revision libraries, for example
"... also have to be created and maintained by the user.
So comparing them to accessing past revisions through normal means in
subversion is not a fair, or even really meaningful, comparison." (Daniel
Berlin).</li>
<li>When comparing Arch's repositories to Subversion's there is no
speed advantage. Arch's storage is either diffy (storing only differences),
in which case it is not easily browsed and is no faster (at best) than
Subversion; or the storage isn't diffy, in which case it isn't efficiently
stored (imagine multiple copies of each file for each revision).</li>
<li>Subversion's choice of BDB as a backend was not accidental. Some of
the tools Subversion got from using BDB are: Hot
backup and replication, all kinds of existing tools that know
about BDB databases (e.g. Python or Perl bindings). A body of -
"community" knowledge. etc (Greg Stein).</li>
</ul>
I've left out vaporware features, such as the future SQL backend of
Subversion 2.0.
=== END
- --
|.. "Even the Mongols rejected Communism... are we more dumb?"
<|> --- Russian newspaper headline supporting Yeltzin's 1996 campaign
/|\
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8YKbTP0KxygnleI8RAmNLAJ4iuhMoCIdjgGztEBXPgJn6DyL8VwCgsaEt
lelPKMnsxSCPtNowKXy7EM0=
=cgr+
-----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