Reid Spencer
2004-May-02 08:48 UTC
[LLVMdev] Open Source Contributions (was Re: Benchmarks)
On Sat, 2004-05-01 at 20:57, Chris Lattner wrote:> > (b) move the CVS repository somewhere that doesn't have the University's > > restrictions. That last option, however, may have additional > > intellectual property issues. > > I don't think that there would be IP issues: LLVM is (effectively) BSD > licensed, so it could be forked at any time without a problem. This would > obviously be very bad for LLVM, but it's possible.I don't see moving the repository to another system and forking the code base as equivalent. I agree that its definitely not time to fork the code base. But we can change the source code control repository without forking.> > The more I've thought about this, the more that I'm beginning to realize > that CVS is the root of the problem. Perhaps it is time for LLVM to > seriously start looking at switching over to a decentralized version > control system? I really am not "up" on the various options, but I've > heard rumars that there are now several good options. > > Take 'arch' for example: its approach seems like it would solve almost all > of the version control issues that we are facing, and supports > decentralized development in particular. From what I understand, you > would be able to do all of your development on your own "local" branch, > others could have access to it, and when it's ready, we could pull it in > as one big patch or set of changes.I've looked at subversion recently. Setting it up wasn't a big deal but its much more complicated than CVS (e.g. you have to get a specific version of Berkley DB). Also, there are enough problems with it that I deem it unstable. The last thing we need is a buggy SCC system. I think Subversion is a good choice (functionality wise), it just isn't quite ready yet. Perhaps by release 1.2 or so the main issues will have settled down. I haven't looked at arch but I will.> > >From your perspective, would this solve the problem? I used arch just as > an example, I'm sure there are others (bitkeeper at least supports these > features, but has unattractive licensing issues).The main problem isn't the SCC tool that we use. They all have their good and bad points. The main problem is not being able to check things in to a branch. As long as the SCC tool supports distributed and parallel development (i.e. is WAN network based and supports branches), it will be fine. So, I'm rejecting SCCS and RCS but not CVS.> > If it is really time to switch version control systems we probably should > have someone do some research and find out which one is the most > appropriate. Assuming that we can come up with a reasonable transition > phase, I think that this could be done.Sounds right. Its not a decision to be made lightly. 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/20040502/dfc68e91/attachment.sig>
Chris Lattner
2004-May-02 11:49 UTC
[LLVMdev] Open Source Contributions (was Re: Benchmarks)
On Sun, 2 May 2004, Reid Spencer wrote:> I don't see moving the repository to another system and forking the code > base as equivalent. I agree that its definitely not time to fork the > code base. But we can change the source code control repository without > forking.Sure, I didn't mean to say they were equivalent, it's just that they would both solve this problem.> > Take 'arch' for example: its approach seems like it would solve almost all > > of the version control issues that we are facing, and supports > > decentralized development in particular. From what I understand, you > > would be able to do all of your development on your own "local" branch, > > others could have access to it, and when it's ready, we could pull it in > > as one big patch or set of changes. > > I've looked at subversion recently. Setting it up wasn't a big deal but > its much more complicated than CVS (e.g. you have to get a specific > version of Berkley DB). Also, there are enough problems with it that I > deem it unstable. The last thing we need is a buggy SCC system. I think > Subversion is a good choice (functionality wise), it just isn't quite > ready yet. Perhaps by release 1.2 or so the main issues will have > settled down. I haven't looked at arch but I will.Okay, I agree that dealing with a buggy SCC system is a bad idea. :) Does subversion support distributed development?> > >From your perspective, would this solve the problem? I used arch just as > > an example, I'm sure there are others (bitkeeper at least supports these > > features, but has unattractive licensing issues). > > The main problem isn't the SCC tool that we use. They all have their > good and bad points. The main problem is not being able to check things > in to a branch. As long as the SCC tool supports distributed and > parallel development (i.e. is WAN network based and supports branches), > it will be fine. So, I'm rejecting SCCS and RCS but not CVS.Okay, but one of the nice things about the distributed systems is that branches don't need to be on the "central" machine. You can do all of your development on a local branch (which you can optionally share with others) and then when it's time, the entire branch can be trivially merged back to mainline, preserving the revision history. Vikram makes a good point, though: we don't want to unnecessarily raise the bar of LLVM development to include having to get a non-standard SCC system... hrm. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
Reid Spencer
2004-May-02 12:37 UTC
[LLVMdev] Open Source Contributions (was Re: Benchmarks)
On Sun, 2004-05-02 at 09:54, Chris Lattner wrote:> Okay, I agree that dealing with a buggy SCC system is a bad idea. :) Does > subversion support distributed development?I think subversion will be an excellent choice when its ready. It supports distributed development very well. It is CVSish (existing CVS users will find it familiar). It handles branching and check-in much more cleanly. For example, a check-in gets a revision number, not the individual files. So, the entire set of what you checked in is retained as a logical unit of work. To support authentication and access control it has a plug-in to Apache HTTP Server so all the nice things about a web server are available as well.> Okay, but one of the nice things about the distributed systems is that > branches don't need to be on the "central" machine. You can do all of > your development on a local branch (which you can optionally share with > others) and then when it's time, the entire branch can be trivially merged > back to mainline, preserving the revision history.You can do this with Subversion and to some extent with CVS (the "sharing" a branch thing is tricky in CVS).> > Vikram makes a good point, though: we don't want to unnecessarily raise > the bar of LLVM development to include having to get a non-standard SCC > system... hrm.Yup. subversion will be easy for existing CVS users. That's one of its major design goals. 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/20040502/326bf3ff/attachment.sig>
Vladimir Prus
2004-May-05 01:02 UTC
[LLVMdev] Open Source Contributions (was Re: Benchmarks)
Reid Spencer wrote:> > Take 'arch' for example: its approach seems like it would solve almost > > all of the version control issues that we are facing, and supports > > decentralized development in particular. From what I understand, you > > would be able to do all of your development on your own "local" branch, > > others could have access to it, and when it's ready, we could pull it in > > as one big patch or set of changes. > > I've looked at subversion recently. Setting it up wasn't a big deal but > its much more complicated than CVS (e.g. you have to get a specific > version of Berkley DB). Also, there are enough problems with it that I > deem it unstable. The last thing we need is a buggy SCC system. I think > Subversion is a good choice (functionality wise), it just isn't quite > ready yet. Perhaps by release 1.2 or so the main issues will have > settled down. I haven't looked at arch but I will.I think the decision is up to the developers, but I'd just like to note that your opinion of Subversion is not the only one. In particular, we've being using it at work for something like year (yes, long time before 1.0 was released), and haven't run into any significant problems. Maybe it means that right decision requires some experimenting. - Volodya
Reid Spencer
2004-May-05 18:39 UTC
[LLVMdev] Open Source Contributions (was Re: Benchmarks)
On Wed, 5 May 2004 10:01:11 +0400> >I think the decision is up to the developers, but I'd just like to note >that >your opinion of Subversion is not the only one. In particular, we've being >using it at work for something like year (yes, long time before 1.0 was >released), and haven't run into any significant problems. >Absolutely! I've been watching subversion for a year and playing with it. I'm all in favor of it. I just think there are *still* some rough edges to be smoothed out. I know several large companies are using it and that its generally "okay" at this point. But, I'm still reading on the user's list (this past week) about people losing their entire repositories due to database corruption. I'm not saying that would happen to LLVM, but it doesn't sound like stability to me. When the time is right, I'm all in favor of subversion. And, I *am* one of the developers (a minor one albeit :). Reid.
Possibly Parallel Threads
- [LLVMdev] Open Source Contributions (was Re: Benchmarks)
- [LLVMdev] Open Source Contributions (was Re: Benchmarks)
- [LLVMdev] Open Source Contributions (was Re: Benchmarks)
- [LLVMdev] Open Source Contributions (was Re: Benchmarks)
- [LLVMdev] Open Source Contributions (was Re: Benchmarks)