[Sablevm-developer] Re: prcs vs. cvs vs. subversion

[Lhotak O. <ol...@sa...>]

On Wed, Mar 19, 2003 at 09:50:27PM -0500, Chris Pickett wrote:
> Hi Ondrej,
> 
> Can you send a message to this list discussing why you chose Subversion 
> over PRCS (apart from the lack of client-server functionality)?  Can you 
> also tell us how Subversion is working out for Soot?  Problems, 
> benefits, support ... whatever.  Things like branch management are 
> particularly interesting.
> 
> Cheers,
> Chris

How long a response are you looking for? :)

We agreed that prcs was getting in our way due to missing features and
important bugs. Most annoying missing features were:
- no way to get per-file change log. Result was Soot littered with
  comments like "Who did this? Why? and When?" which any half-decent
  system should easily answer. Even per-repository change log is clumsy.
  If you can't easily see your old versions, why even have version
  control at all?
- no clean way to revert local changes made to a file.
- no network access
Most annoying bugs were:
- the mechanism tracking which versions had been merged often broke,
  causing people to inadvertently undo other peoples' changes, because
  prcs thought it had merged them when it hadn't
- the mechanism for inserting properties such as the version number into
  the versioned files was broken, and often forgot to do it. Someone had
  decided to use it for code (to encode the version string) rather than
  just comments, leading to often uncompilable code.

We agreed that we wanted to switch away from prcs. I evaluated a wide
range of alternatives. This quickly narrowed down to cvs and svn. The
main other runner-ups were arch, bitkeeper, and p4. Arch is still not
stable enough. Judging from its mailing list, there appears to be no
progress. It is overkill and too complicated for our needs. Bitkeeper is
also more complicated than we need; if Soot were being developed by ten
independent groups like Sable, it would probably be a good choice. It
is proprietary, though the free-beer-when-used-for-open-source licence
seems quite reasonable. P4 would probably have been the best choice from
a technical point of view, but it is very similar to svn, and there are
really no compelling reasons to choose it over svn (except perhaps a
bit of maturity). Its disadvantage is that it's proprietary, and its
free-beer-when-used-for-open-source licence appears to require much more
paperwork than the one for bitkeeper.

So it was between cvs and svn. Svn is designed as a replacement for cvs,
meaning that it fixes cvs's design problems, while attempting to
maintain all its features and a similar interface. Key advantages of
svn over cvs:
- Directories and file moves are versioned. This is particularly
  important for Java, since the placement of a file has semantic
  meaning: to move a class to a different package, you must move the
  file to a different directory. An indirect advantage of this is that
  we were able to convert our existing prcs repository into svn. I had
  earlier tried to convert it to cvs, but ended up with a clutter of
  many empty subdirectories which had been removed in prcs.
- Per-repository revision numbers rather than per-file are a nice way to
  keep track of which versions of files go together. Atomic commits are
  nice too.
- Tagging and branching first appear odd to someone corrupted by cvs,
  but if you are not so corrupted, the svn way of doing it is much
  simpler and more intuitive. They support a cheap copy operation.
  To tag, you just make a (cheap) copy of the current state of the
  project. To branch, you make a cheap copy and continue working on it.
- Disconnected operation. Svn makes a full copy of each file you
  checkout in its own .svn directory, so you can perform many operations
  (eg. diff, revert, ...) without being connected to the repository.

The main potential advantages of cvs over svn are maturity/stability,
and third-party tool support. In terms of maturity/stability, the
following is from the svn FAQ:

> Is Subversion stable enough for me to use for my own projects?
> 
> We think so!
> Because:
>     * We believe that Subversion is stable and have confidence in our
> code, in fact, we've been self-hosting since September of 2001--eating
> our own caviar so to speak. We declared alpha because we're ready for
> the world to try Subversion.
>     * After 10 months of self-hosting, we haven't lost any data at all.
>     * The filesystem schema is stable now and shouldn't undergo any
> changes before 1.0. In the off-chance that the schema does change, we
> will provide a dump/load utility to aid you in the migration.
>     * In order to make Subversion as stable as possible, we need more
> people to use Subversion. If you use Subversion on a day-to-day basis,
> you can help us find and fix any bugs that might turn up. It may sound
> risky at first, but odds are that if you find any bugs they will be
> minor inconveniences as opposed to data destroyers.

In my experience (in using svn on Soot and other toy projects, and
when evaluating it), the back end is rock solid, while the front-end
exhibits the odd minor annoyance. None of the annoyances I've seen were
data-destroying; typically, they affect the client-side metadata in the
workspace. Pat claims that cvs sometimes has similar annoyances; we've
certainly seen many more with prcs than with svn. Development is very
active (I couldn't keep up with the mailing list), and bugs are fixed
promptly. There are typically about two releases a month.

As far as third-party support, it is catching up fast. We were
particularly interested in ViewCVS, which does support svn.

One to-be-implemented feature is the equivalent of cvs annotate (the
blame finder); it is planned for this summer. For the impatient, there
exists a free perl script to do this with p4, and it would probably be
easy to modify to work with svn.

You asked about branching and merging. Currently, svn gives you full
control over a merge, and (unlike prcs) doesn't try to guess which
version(s) you meant. Specifically, svn merge takes as arguments three
(versions of) directories. It makes a diff from dir1 to dir2, and then
uses it to patch dir3. Then you get to resolve any conflicts. This works
very well if you have, say, a stable and a development branch, and you
want to port a specific change (bug fix) from one to the other. It works
slightly less well if you have an experimental branch with new features,
and you want to merge the whole branch into your main branch, especially
if you've already merged specific changes from the main branch into the
experimental branch. This is the same with cvs. Remembering what has
already been merged and using that information in future merges is a
to-be-implemented feature.

You asked how it's working out for Soot. Svn is a joy to use compared to
prcs, which was a constant source of frustration. I suspect that cvs
would be similar, but I have no regrets about having chosen svn over
cvs. As far as support, the only problems that we encountered were
already reported and fixed before we encountered them, so we haven't
needed to ask for any support.

I hope this answers your question. I am not subscribed to sablevm-dev,
so please cc me any followups.

Ondrej