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. 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050107/f89ee50c/attachment.html>
On Fri, Jan 07, 2005 at 04:35:35PM -0800, Reid Spencer wrote:> 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.As the person maintaining a repository and someone using working copies I much prefer subversion to cvs. I found the move from cvs to subversion using the cvs2svn tool painless for a repository without tags. I have not used tags in cvs. Setting svn:eol-style correctly so text checkouts work to unix and dos can be a pain. Make sure all commiters use auto-props and you may want to set up http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl I not familiar with arch or monotone, but would encourage cvs users to change to svn. It was handy that you were still using cvs in the fall semester because our group used subversion on top of a cvs checkout. Tom -- Tom Brown tdbrown at uiuc.edu Siebel Center 2107 +1 (217) 778-7908
Le 8 janv. 05, à 01:35, Reid Spencer a écrit :> 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.From my experience, monotone is the cleanest. It has a very simple and powerful versionning model (based on SHA-1 signatures), and does not clutter your directories with hidden folders to store versionning info (everything lies in a single folder). However, Subversion is gaining a wide acceptance as a replacement to CVS, is updated regularly and seems to "work" -- but for people knowing Monotone, Subversion model looks somewhat old. This drawback is really minor, as there are a lot of really cool tools (such as Trac <http://www.edgewall.com/trac/>) which supports SVN and offer very valuable features. Arch seems only interesting for people who do not have a server on which they can put a Monotone or SVN server, however it's starting to gain some acceptance in the GNU community. Hope this helps, -- Sébastien -- «Life begins at the centerfold and expands outwards.» <http://www.type-z.org> -- Miss November, 1966
On Friday 07 January 2005 18:35, 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. > > 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 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.I believe subversion does not support "Remote Repository Replication" but svk does (a modified version of subversion). After reading the docs for these VCS I don't think there is a clear choice today. Subversion lacks distributed development. Arch supports distributed development but forces you to have srcdir != objdir (not necessarily bad, but i want the choice) and it also has akward commands. Monotone seems very clear on how it works but lacks a web interface and is unclear how mature it is. If we don't care about the web interface I suggest we give monotone a try. -- Alkis
Hi everyone, Reid said:> 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.Apart from using CVS as a client (as everyone does), I've only ever used Aegis (previous employer, for ~3 years) and Perforce (the employer before that, though ever since then I've been using the 'free' license for personal stuff.) I've tinkered a bit with some of the shiny new V-C systems. Well, to put things bluntly, Aegis was a complete and total disaster, while Perforce is the best version control system I've ever used. Why? Ease of use! Something that isn't mentioned in the version control system comparison Reid mentions. For good reason, no doubt - it is to _some_ extent a subjective thing. However, Perforce has always been an absolute joy to use (I can't stress this enough!!) while Aegis always struck me as more or less designed to _inhibit_ development! (It really does live up to its name on this point, trust me.) The differences can't _all_ be in my head, I hope! OK, I should at least _try_ to be objective. In contrast to the other VCSs I've used: - Perforce _just works_. By this I mean that it only ever takes effort to make it work _differently_, not to make it work _at all_. I don't want to start a flamewar and so won't mention other VCSs that could be contrasted here, but the differences are certainly there. Getting up and running - Perforce is _very_ well documented. - Perforce is _very_ well supported: should anyone ever need help, Perforce support is incredibly helpful, polite and _eerily_ rapid to respond. At this point I should mention that the VCS comparison says that no support is available for people using Perforce with a free open-source license. This is indeed "the letter of the law", but the reality is that Perforce support tries to help everyone on a best-effort basis. Indeed, the support is so good (I'd never experienced anything like it, and haven't since) that I'm quite sure the guys who write the software are the same guys who answer the emails. It's like LLVM support in that regard. :) - Perforce is basically idiot-proof. By this I mean that you really need to know what you're doing to lose/mess up data/configuration. Perforce is the closest thing out there to a VCS with an "undo button", as far as I'm aware. - Perforce is basically bug-free. For every genuine bug an LLVMer finds in Perforce, I will send him or her a box of chocolates and a handwritten apology. :) It's difficult for me to make a strong case that LLVM should switch to Perforce because I haven't had any problems with the _current_ system, but if we are to switch, I'd recommend Perforce highly. It does everything people ever seem to ask of a VCS, and it's quick, easy and fun to use. Really! If you has half an hour to burn, visit http://perforce.com , download the software and have a play. You get "the real thing", the only difference is that without a license file, you can't create more than two accounts or workspaces. Perforce is not the fanciest thing out there, but it's simple and it works well. My two yen, Duraid P.S. Perhaps a minor point in this era of 400GB hard disks and 2GHz CPUs, but worth mentioning: Perforce is _FAST_.
Oops, munched a sentence. where I wrote:> - Perforce _just works_. By this I mean that it only ever takes > effort to make it work _differently_, not to make it work _at all_. I > don't want to start a flamewar and so won't mention other VCSs that > could be contrasted here, but the differences are certainly there. > Getting up and runningI meant to continue: Getting up and running won't be a problem - while it's different from CVS, it's easy to install and there's ample support for importing CVS archives. Duraid
I have used Perforce also and fully agree it's wonderful. The only concern I have is with their license for open source projects. The only gotcha is that it must be renewed annually, and they reserve the right to not renew it (though they say they won't unreasonably deny renewals). Not sure how much this really matters, as Perforce strikes me as being one of those "do no evil" companies. Duraid Madina wrote:> Hi everyone, > > Reid said: > >> 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. > > > Apart from using CVS as a client (as everyone does), I've only ever > used Aegis (previous employer, for ~3 years) and Perforce (the > employer before that, though ever since then I've been using the > 'free' license for personal stuff.) I've tinkered a bit with some of > the shiny new V-C systems. > > Well, to put things bluntly, Aegis was a complete and total disaster, > while Perforce is the best version control system I've ever used. > > Why? Ease of use! Something that isn't mentioned in the version > control system comparison Reid mentions. For good reason, no doubt - > it is to _some_ extent a subjective thing. However, Perforce has > always been an absolute joy to use (I can't stress this enough!!) > while Aegis always struck me as more or less designed to _inhibit_ > development! (It really does live up to its name on this point, trust > me.) The differences can't _all_ be in my head, I hope! > > OK, I should at least _try_ to be objective. In contrast to the other > VCSs I've used: > > - Perforce _just works_. By this I mean that it only ever takes > effort to make it work _differently_, not to make it work _at all_. I > don't want to start a flamewar and so won't mention other VCSs that > could be contrasted here, but the differences are certainly there. > Getting up and running > > - Perforce is _very_ well documented. > > - Perforce is _very_ well supported: should anyone ever need help, > Perforce support is incredibly helpful, polite and _eerily_ rapid to > respond. At this point I should mention that the VCS comparison says > that no support is available for people using Perforce with a free > open-source license. This is indeed "the letter of the law", but the > reality is that Perforce support tries to help everyone on a > best-effort basis. Indeed, the support is so good (I'd never > experienced anything like it, and haven't since) that I'm quite sure > the guys who write the software are the same guys who answer the > emails. It's like LLVM support in that regard. :) > > - Perforce is basically idiot-proof. By this I mean that you > really need to know what you're doing to lose/mess up > data/configuration. Perforce is the closest thing out there to a VCS > with an "undo button", as far as I'm aware. > > - Perforce is basically bug-free. For every genuine bug an LLVMer > finds in Perforce, I will send him or her a box of chocolates and a > handwritten apology. :) > > > It's difficult for me to make a strong case that LLVM should switch to > Perforce because I haven't had any problems with the _current_ system, > but if we are to switch, I'd recommend Perforce highly. It does > everything people ever seem to ask of a VCS, and it's quick, easy and > fun to use. Really! > > If you has half an hour to burn, visit http://perforce.com , download > the software and have a play. You get "the real thing", the only > difference is that without a license file, you can't create more than > two accounts or workspaces. > > Perforce is not the fanciest thing out there, but it's simple and it > works well. > > My two yen, > > Duraid > > P.S. Perhaps a minor point in this era of 400GB hard disks and 2GHz > CPUs, but worth mentioning: Perforce is _FAST_. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > >
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
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>
John Criswell wrote:> 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).I turned down the priviledge of having write access to the CVS because of problems with the software. I will describe the root cause of the problem: We are also using CVS locally, and I need to have the LLVM version that we use with our project as part of our CVS so we can tag it when we make releases. Since I also want to sync with the LLVM repository, I have to have two copies of LLVM and manually copy files across. At some point I managed to copy also a CVS directory across and when I tried to check in to our own repository I was actually checking in to the LLVM repository. Luckily I did not have write access. If I could have write accesss only to the win32 directory tree it would be OK since our local version should match the official version for this part of the tree, and I'm actively working on it and submitting patches to the mailing list. But CVS does not let you have different priviledges for different parts of the source tree (at least I don't know how to set it up). The other clear deficiency of CVS is that it's not possible to sync the local version with several repositories, I believe the version controls systems which claim to support distributed development support this kind of scenario. > 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)? There you have it, this is what I find wrong with CVS on a day to day basis. If it's important enough to fix it is up to the oversight comittee to decide ;-) By the way, the LLVM _users_ are supposed to use the releases which are distributes as tarballs, and have no need to access the repository - The way I see it, it's the contributors who will need to download a new program... m.
>> 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).Considering that everyone is managing just fine with cvs, anything discussed about the differences between cvs and *X* is not a show stopper. -Tanya