[LLVMdev] Open Source Contributions (was Re: Benchmarks)
reid at x10sys.com
Sun May 2 08:48:01 PDT 2004
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the llvm-dev