← Back to branch summary

~svn/ubuntu/raring/subversion/ppa

« back to all changes in this revision

Viewing changes to www/bitmover-svn.html

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-12-05 01:26:14 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20051205012614-qom4xfypgtsqc2xq
Tags: 1.2.3dfsg1-3ubuntu1
Merge with the final Debian release of 1.2.3dfsg1-3, bringing in
fixes to the clean target, better documentation of the libdb4.3
upgrade and build fixes to work with swig1.3_1.3.27.

Show diffs side-by-side

added added

removed removed

Lines of Context:
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>
 
4
<head>
 
5
<style type="text/css"> /* <![CDATA[ */
 
6
  @import "tigris-branding/css/tigris.css";
 
7
  @import "tigris-branding/css/inst.css";
 
8
  /* ]]> */</style>
 
9
<link rel="stylesheet" type="text/css" media="print"
 
10
  href="tigris-branding/css/print.css"/>
 
11
<script type="text/javascript" src="tigris-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 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>