[LLVMdev] Version Control Upgrade?

[Reid Spencer]

John,

Here's my list:

1. CVS is slow. Many of the other tools do bi-directional binary deltas
on file changes they are transmitting. This is basically the technology
that makes rsync so fast. CVS doesn't do this. Probably not a big deal
when you're working at UIUC but its CRUCIAL when I'm on the road working
from a hotel or airport wi-fi connection.

2. Related to 1 is diff speed. Subversion, at least, keeps a local copy
of the original (unmodified) version of each file. This makes "svn diff"
instantaneous and doesn't require it to go over the wire. That also
helps make the server more scalable as it off loads work from the
server.

3. CVS doesn't have atomic commits or the notion of a change set. This
has bitten me several times when I'm doing a large commit .. users
update and get .h files out of sync with .cpp files or other
inconsistencies. That never happens with the tools that support atomic
commit (most of them).

4. As you mentioned, file & directory copy/move aren't supported in CVS.
This is a pain at times as I have to contact someone at UIUC to "copy
the ,v file". This bit me over the holidays as no one at UIUC was
available for a day or two.  I'm sure you'd all rather not have to deal
with such requests. Chris ends up taking the brunt of these requests.
Many of the other tools support moving and copying files around.

5. CVS doesn't support distributed development well. Tools such as Arch
and Monotone work on a peer-to-peer basis. No one computer is "the
repository". If the CVS server should ever go down (heaven forbid), we'd
all be out of luck. With a peer-to-peer we'd just switch to the most
relevant/up-to-date other repository. This also allows you to take the
repository with you when you travel and still be able to
commit/diff/checkout while not connected to a network. When you get back
you can synchronize with the rest of the world and all your commits will
be rolled into the other repositories. Note that Subversion has limited
support for this via the svn-push and SVN::Mirror utilities. These
essentially keep two repositories in synch. Not sure how scalable that
is.

6. Authorization. Arch/Monotone/Subversion/Perforce all have fine
grained authorization (permission) features. CVS does not. This means we
can't say, "user xyz is given write access only in lib/System" .. we
either give them write access to the whole repository (or a module) or
not at all.

7. Authentication. CVS passwords are notoriously easy to crack and
shipped over the net in plaintext when using pserver. Using SSH would
help but that means giving every developer a login account on the CVS
server. I'm sure UIUC doesn't want to do that. I'm not sure about the
others but Subversion handles this really well via that WebDAV
(Distributed Authoring and Versioning) Apache plug-in. All requests go
via HTTP and the web servers authorization and authentication mechanisms
can be used. This also helps with getting around firewalls.

My $0.02 worth.

Reid.

On Mon, 2005-01-10 at 07:52, John Criswell wrote:
> Reid Spencer wrote:
> > LLVMers,
> > 
> > The oversight group has been kicking around the idea of getting a better 
> > version control system than CVS. The problem is, we're not quite sure 
> > what "better" means. So, we thought we'd ask your opinions.
> 
> I think before we begin discussing which software to use, we should 
> discuss what is really wrong with CVS (on a day to day basis) and how 
> important it is to fix it (and I apologize if it has been discussed; I 
> just haven't seen it discussed in this thread).
> 
>  From all the features listed below, file/directory renames and moves 
> are the only missing feature that, to me, warrants changing to another 
> program (and maybe access control, but I haven't looked into that much). 
>    Everything else looks like something that would be nice to have, but 
> isn't critical.
> 
> So, what exactly are people finding wrong with CVS on a day to day 
> basis, and is it important enough to fix it (fixing it will mean that 
> users will need to download a new program to use the repository, which 
> is a disincentive to using LLVM)?
> 
> -- John T.
> 
> > 
> > If you're interested in this topic (and you should be if you're actively 
> > developing), please have a look at this site: 
> > _http://better-scm.berlios.de/comparison/comparison.html_
> > <http://better-scm.berlios.de/comparison/comparison.html#move> It has 
> > quite a nice comparison of key features that we're interested in. Some 
> > of the features we think are important are shown in the list below. The 
> > text in square brackets is the corresponding item at the comparison site.
> > 
> >     * [Atomic Commit] - all changed files in a change set get committed
> >       or none of them do.
> >     * [Repository Permissions] - control read/write access to the
> >       repository on a per-user basis, preferably allowing the
> >       authentication to be hooked into an apache server (like mod_webdav).
> >     * [Files and Directories Moves or Renames] - make sure moves and
> >       renames of both files and directories are tracked as well as edits.
> >     * [Remote Repository Replication] - ability to clone a repository
> >       and "take it with you" so you can commit changes while
> >       disconnected from the network. This supports distributed development.
> >     * [Change set support]. Groups together related changes in multiple
> >       files as a logical "change set". This helps when you need to back
> >       out (revert) a change or the change needs to be propagated to
> >       another repository because all the related changes are managed as
> >       a group.
> >     * [Tracking Line-wise File History] - basically support stuff like
> >       cvs annotate to see who modified the file and when on a
> >       line-by-line basis. 
> > 
> > 
> > Of the tools available, it seems that only subversion, arch, and 
> > monotone are suitable for our purposes. But, we'd love to hear your 
> > thoughts; especially if you have first-hand experience with these tools.
> > 
> > Thanks in advance,
> > 
> > Reid
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050110/5f39cc8b/attachment.sig>