[LLVMdev] Version Control Upgrade?

John Criswell criswell at cs.uiuc.edu
Mon Jan 10 09:29:53 PST 2005 

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).

Okay.  I guess this is happening because our CVS server is much slower 
for you than it is for me, which is why I never have this problem.  So 
this is more important than I thought.


> 
> 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.

Agreed.  This is a pain, and I forgot that you can't just move stuff 
around like we can here.

> 
> 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.

How important do you (and others) feel this feature 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.

Agreed, but has this posed a serious enough problem (or do we forsee it 
becoming a serious problem)?  I tend to doubt that we'll be segmenting 
access to various pieces of the LLVM codebase.

> 
> 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.

So far this hasn't posed a serious problem, but as we get more external 
developers, it will.  And the firewall note is also a good point.

Thanks.

-- John T.

> 
> 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

More information about the llvm-dev mailing list