www/bitmover-svn.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4 <head>
   5 <style type="text/css"> /* <![CDATA[ */
   6   @import "branding/css/tigris.css";
   7   @import "branding/css/inst.css";
   8   /* ]]> */</style>
   9 <link rel="stylesheet" type="text/css" media="print"
  10   href="branding/css/print.css"/>
  11 <script type="text/javascript" src="branding/scripts/tigris.js"></script>
  12 <title>Debunking BitMover's Subversion Comparison</title>
  13 </head>
  14
  15 <body>
  16 <div class="app">
  17
  18 <h2>Debunking BitMover's Subversion Comparison</h2>
  19
  20 <h3>Summary</h3>
  21
  22 <p>BitMover, Inc. offers a comparison between BitKeeper (their main
  23 product) and Subversion, at</p>
  24
  25 <blockquote>
  26 <p><a href="http://www.bitkeeper.com/Comparisons.Subversion.html"
  27            >http://www.bitkeeper.com/Comparisons.Subversion.html</a></p>
  28 </blockquote>
  29
  30 <p>BitMover's comparison contains various false statements about
  31 Subversion, and some misleading statements.  Below, we analyze
  32 BitMover's page and set the record straight about Subversion.  The
  33 entire relevant content of the BitMover page is quoted below, as it
  34 looked on 2 July 2004.  We've omitted only extraneous things like
  35 navigation links and the endorsement quote at the top of the
  36 page.</p>
  37
  38 <p>Please note that this response is strictly about Subversion.  We
  39 have no complaints about BitKeeper as a piece of software; we've heard
  40 mainly good things about it, though we can't try it ourselves because
  41 of its <a href="#licensing">license situation</a>.</p>
  42
  43 <p>BitMover's text below is quoted in red italics where we feel it's
  44 in error, and green italics otherwise.  Our annotations are in regular
  45 black text.</p>
  46
  47 <h3>The Response</h3>
  48
  49    <blockquote>
  50    <p style="color: red"><i>Subversion is a new system
  51    which is supposed to replace CVS. Unfortunately, Subversion shares
  52    many of CVS' problems and introduced some of its own
  53    problems:</i></p>
  54    </blockquote>
  55
  56 <!-- Commenting out this minor complaint for now:
  57
  58 <p>I like how they subtly imply that Subversion <i>only</i> adds new
  59 problems on top of CVS's, without solving any problems.  It solved
  60 many, of course, and while this quote doesn't explicitly deny that,
  61 it's worded in a very misleading way.</p>
  62
  63 <p>Moving on to more substantive stuff:</p>
  64
  65 -->
  66
  67    <blockquote>
  68    <p style="color: red"><i>Subversion uses a binary file format for
  69    your revision control data and metadata and if that format gets
  70    corrupted you are out of luck, your whole team comes to a
  71    halt.</i></p>
  72    </blockquote>
  73
  74 <p>That bit about the binary format is classic <a
  75 href="http://www.catb.org/~esr/jargon/html/F/FUD.html">FUD</a>.  It's
  76 quite true that Subversion uses a binary file format, but think about
  77 it: BitMover is basically saying that databases are a bad idea, since
  78 virtually all modern databases use a binary format.  Sure, if anything
  79 happens to those files, you're out of luck, assuming you have no
  80 backup.  So, does this mean no one should ever use a database?</p>
  81
  82 <p>Anyone who runs, say, Oracle, MySQL, Postgres, or another database
  83 system should be able to see the silliness here right away.
  84 Furthermore, it's clearly the case that if BitKeeper's data storage
  85 format got corrupted severely enough, your whole team would come to a
  86 halt too, at least for as long as it took to get everything fixed,
  87 restored from backup, whatever.  Not so different from Subversion,
  88 really.</p>
  89
  90 <p>There are database management issues to administering a Subversion
  91 repository, of course, issues which CVS does not have.  If this is
  92 BitMover's complaint, then they should say so, rather than making a
  93 meaninglessly broad generalization.  (Note that Subversion now offers
  94 a non-database back end, for those who don't want the overhead of
  95 administering a database.  This is a fairly recent development, and
  96 it's likely that BitMover simply hadn't heard about it yet when they
  97 wrote their page.)</p>
  98
  99    <blockquote>
 100    <p style="color: green"><i>Subversion has a single repository model,
 101    i.e., client/server. Each work area is clear text only which means
 102    no revision control in the work area during
 103    development.</i></p>
 104    </blockquote>
 105
 106 <p>This is basically true, though note that this way seems to work
 107 fine for a lot of people.  Strictly speaking, Subversion has exactly
 108 one level of revision control in the working copy, since there are
 109 pristine base texts of every file present.  One can locally view one's
 110 changes, revert them, or save them and then revert, all without a
 111 network connection.</p>
 112
 113    <blockquote>
 114    <p style="color: red"><i>No staging areas to protect the main source
 115    tree. With Subversion, everyone checks into the same place and if
 116    someone breaks the tree, it's broken for everyone. With BitKeeper,
 117    you can put a staging area between each group of developers and the
 118    main integration tree, thereby protecting the main tree from bad
 119    checkins. Anyone who has lived through a change that broke the
 120    build can see the value of staging areas.</i></p>
 121    </blockquote>
 122
 123 <p>False and FUD.</p>
 124
 125 <p>Having a staging area is a matter of how the project organizes its
 126 repository and moderates its commits.  The fact that some projects
 127 choose to use their main development trunk <i>as</i> their staging
 128 area, and release from branches, is a matter of policy, not of
 129 technical limitations.  If you want to insert an extra level of
 130 staging area, Subversion supports that just fine.</p>
 131
 132 <p>Now, there might be a kernel of a real complaint here, which is
 133 that Subversion doesn't have first-class changeset swapping, and
 134 therefore merges from one branch to another (say, from staging to
 135 live) don't preserve as much history as they could.  However,
 136 BitMover's text goes far beyond that simple, circumscribed complaint.
 137 And since they make the merge complaint separately later anyway, they
 138 either thought they were saying something different here, or they're
 139 making the same claim twice, for the sake of inflating their page.</p>
 140
 141    <blockquote>
 142    <p style="color: green"><i>Subversion loses information every time
 143    there is parallel development because you are forced to merge
 144    before you check in if someone else checked in first. The state of
 145    your workspace before the merge is lost forever. Another way to say
 146    this is that if there is N-way parallel development, Subversion
 147    loses N-1 events.</i></p>
 148    </blockquote>
 149
 150 <p>As worded, this is not quite true.  But probably what they meant to
 151 say was "you are forced to merge before you check in if someone else
 152 checked in changes <i>to the same files</i> first."  Then it would be
 153 true.</p>
 154
 155 <p>So how important is it?  It depends whom you ask.  BitMover
 156 probably has in mind the "star merge" work style that has developed in
 157 the Linux family of OSs, where there is never any expectation that all
 158 workspaces will converge onto a single canonical form.  It's not about
 159 how far behind you are, but about how different you wish to remain;
 160 less about merging than about cherry-picking.  There are Subversion
 161 users who ask for this.  We usually point them to <a
 162 href="http://svk.elixus.org/">SVK</a>, which is based on Subversion
 163 and supports this style of development, or to <a
 164 href="http://www.gnuarch.org/">Arch</a>, an open-source revision
 165 control system unrelated to Subversion.  But some others do not find
 166 this a compelling feature; see <a
 167 href="http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot" >Greg
 168 Hudson's explanation</a> why not.</p>
 169
 170    <blockquote>
 171    <p style="color: green"><i>Merging in Subversion is no better than
 172    CVS, i.e., primitive at best.</i></p>
 173    </blockquote>
 174
 175 <p>This is basically true.  Subversion's merging <i>interface</i> is
 176 better than CVS's, but the underlying operation leads to the same
 177 result as in CVS.  Better merge support is on Subversion's long-term
 178 todo list.</p>
 179
 180    <blockquote>
 181    <p style="color: red"><i>Branch management in Subversion is a
 182    nightmare.</i></p>
 183    </blockquote>
 184
 185 <p>This is false, at least insofar as it means anything at all.
 186 Without more technical substance to respond to, it's hard to know what
 187 to do with such a claim; they don't say anything more concrete than
 188 "nightmare", unfortunately.</p>
 189
 190 <p>Branch management is actually one of Subversion's strengths.  In
 191 Subversion, branches are first class, versioned objects, just like
 192 regular paths.  They can be copied, renamed, deleted, and
 193 resurrected&nbsp;&mdash;&nbsp;and people do these things all the time.
 194 Perhaps BitMover was really talking about merging?  But again, they
 195 make the merging complaint elsewhere, so this item must presumably be
 196 about something else.</p>
 197
 198    <blockquote>
 199    <p style="color: red"><i>Subversion has no integrity checker which
 200    means files can be silently corrupted and you will never know until
 201    you try and roll backwards.</i></p>
 202    </blockquote>
 203
 204 <p>False.  Subversion ships with an integrity checker
 205 (<tt>svnadmin&nbsp;verify</tt>).  It also attaches a checksum to every
 206 revision of every file.  It verifies these checksums automatically at
 207 every opportunity where it wouldn't have a serious impact on
 208 performance; furthermore, it offers you the ability to paranoidly
 209 check integrity even <i>more</i> often, if you want to, via the
 210 abovementioned command.  So we really don't know what they're trying
 211 to say here.</p>
 212
 213    <blockquote>
 214    <p style="color: red"><i>Subversion has only weak rename support,
 215    that's something that is inherent in all centralized
 216    systems.</i></p>
 217    </blockquote>
 218
 219 <p>It's true that Subversion has weak rename support (work is under
 220 way to fix this).  We don't see any reason why this is inherent in
 221 centralized systems, or even why it has anything to do with
 222 centralization or lack of same.  It sounds as if BitMover is trying to
 223 imply that Subversion, due to its design, simply <i>can't</i> have
 224 good rename support.  That's the more serious charge here, and we
 225 believe it's totally bogus.</p>
 226
 227 <h3>Conclusion:</h3>
 228
 229 <p>What's really going on is that BitKeeper has just one or two solid
 230 complaints to make: "Subversion has only primitive merge capability",
 231 and possibly "Subversion doesn't do decentralized versioning."</p>
 232
 233 <p>While these are true, it seems like BitMover is attempting to say
 234 each one multiple times, to have a longer itemized list of
 235 deficiencies in Subversion.  If we ever write up our own comparison
 236 between Subversion and BitKeeper, we'll avoid that sort of inflation.
 237 Unfortunately, we can't easily make such a comparison, because
 238 BitMover, Inc changed its license to prevent free software developers
 239 who work on competing products (such as Subversion) from using
 240 BitKeeper.</p>
 241
 242 <a name="licensing"></a>
 243 <h3>BitKeeper's Licensing Situation:</h3>
 244
 245 <p>Before they changed their license, anyone could use BitKeeper for a
 246 free software project (with a few minor caveats).  Although BitKeeper
 247 was not "free" or "open source" in any important sense, since BitMover
 248 still retained strong intellectual property rights over the code, it
 249 did mean that free software developers could try it out and learn from
 250 it.</p>
 251
 252 <p>Then BitMover added a clause to their license, ending this
 253 availability for Subversion developers and others:</p>
 254
 255 <pre>
 256     (d)  Notwithstanding any other terms in this License, this
 257          License is not available to You if You and/or your
 258          employer develop, produce, sell, and/or resell a
 259          product which contains substantially similar capabil-
 260          ities of the BitKeeper Software, or, in the reason-
 261          able opinion of BitMover, competes with the BitKeeper
 262          Software.
 263 </pre>
 264
 265 <p>(We'd include a reference to the full license here, but it appears
 266 one must fill out a download form even to get to the license's
 267 <i>text</i>, and that's a little more trouble than we're willing to go
 268 through.)</p>
 269
 270 <p>Larry McVoy, founder of BitMover, <a
 271 href="http://marc.theaimsgroup.com/?l=linux-kernel&amp;m=103384262016750&amp;w=2"
 272 >confirmed</a> that the new clause prohibits Subversion developers
 273 from trying BitKeeper at no charge.  Of course, Subversion developers
 274 are free to purchase a license, but that is not a realistic option for
 275 most of them.</p>
 276
 277 You can read more about the BitKeeper license controversy at these links:
 278
 279 <ul>
 280 <li><a href="http://www.oreillynet.com/pub/wlg/2107"
 281             >http://www.oreillynet.com/pub/wlg/2107</a>
 282 </li>
 283 <li><a href="http://better-scm.berlios.de/bk/bk_suitability.html"
 284             >http://better-scm.berlios.de/bk/bk_suitability.html</a>
 285 </li>
 286 <li><a href="http://better-scm.berlios.de/bk/relicensing_bk.html"
 287             >http://better-scm.berlios.de/bk/relicensing_bk.html</a>
 288 </li>
 289 </ul>
 290
 291 <p>This is why we cannot make our own page comparing Subversion and
 292 BitKeeper.  Of course, BitMover employees are free to download and
 293 install Subversion any time, and we encourage them to do so.</p>
 294
 295 </div>
 296 </body>
 297 </html>