[LLVMdev] Version Control Upgrade?

[Bill Wendling]

Hi all,

My 2 cents as well:

Here where I work (The MathWorks), we have hundreds of developers. We
use CVS but we've had to write several thousand lines of Perl to make it
useful to us (through revisions, branching, testing, and integration).
Mercifully, we're planning on going to another system.

In short, CVS doesn't scale well. It also doesn't having good branching
capabilities (or, rather, there are other tools that do branching
better).

I think to rely upon CVS for all important, large-scale projects (like
LLVM will become) is a mistake.

-bw

(Apologies for the top-post...Reid started it ;-P)

Reid Spencer wrote:
} 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



} _______________________________________________
} LLVM Developers mailing list
} LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
} http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev


-bw

--
||  "It's not stupid. It's advanced." - Purple Tallest