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>
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
I can second this as well also. Many startups start out using cvs because its free (as in beer), and most everyone knows it so little time is wasted setting things up. But as the company grows, cvs becomes a gigantic pain in the ass because it indeed does not scale. Unfortunately, deciding on the VCS to switch to typically also becomes a gigantic pain in the ass, and the larger the company is the more painful it is, so much so that CVS remains in use far longer than is sane. LLVM is small enough now for CVS to relatively pain-free, but it's not likely to stay that way. And it's better to change now if possible, because the larger LLVM gets and the more developers you have, the more painful it will be to change. Bill Wendling wrote:>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 > >_______________________________________________ >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:> 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
On Mon, 2005-01-10 at 09:29, John Criswell wrote:> Reid Spencer wrote: > > > > 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.Yeah, not everyone's on your high-speed network. At some point the non-UIUC developers will out number the UIUC ones. Network efficiency and scalability will become very important because data will be coming from all over the world. We already have patches being submitted from Germany, Russia, Japan, and probably a few other places I'm not aware of.> > > > 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.Yup.> > > > > 5. CVS doesn't support distributed development well. > > How important do you (and others) feel this feature is?Right now, its probably not a big deal. When we have significantly more developers it will become crucial. Not only will it scale better but it will actually let remote developers be more productive than they can with a centralized server. I travel on planes a lot and would *LOVE* to take a copy of the repository with me when I do.> > > > 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.I do. As the number of developers grow we'll want to control who has write access where so that the *developers* can feel safe about what they can change and what they can't. See Morten's response for a case in point.> > > > > 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.Yup. Its not a big deal right now because we're all a friendly bunch and the community is relatively small. As our numbers start to grow, LLVM gets a following, and we get more notoriety, there will definitely be some problems in this area. We can't just trust everyone on the planet to be good net citizens. Look at what happened to GNU's web site when they were cracked .. took them months to get it sorted out. Reid. -------------- 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/743e5ad0/attachment.sig>
On Mon, 10 Jan 2005, John Criswell wrote:>> 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...> How important do you (and others) feel this feature is?I see this as being a pretty big deal. This is exactly the situation Morton is in for example. I also experience this when travelling: I end up building up a whole bunch of changes in a local checked out tree. When I get back to net access, I have to tease all of the patches apart or (more commit) just commit a big blob, losing the individual changes. With a distributed system, I could perform all of the standard operations (commits, diffs, etc) remotely, then apply all of teh change sets to the main repo when I get net access.>> 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.I don't see this as being a big deal. Having per-module access control is enough, at least so far. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On Monday 10 January 2005 11:29, John Criswell wrote:> > 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?This allows two very important (IMO) features: a. You can work offline. b. Experimenting on new ideas (research?) is easier as you can create private branches (the local copy of the repository). With private branches you can have version control of the local changes you are making which is very important especially if the change is pretty big. Note that as an added benefit, this model of VC makes it easier for people with read access only to contribute to llvm. -- Alkis