llvm dev - May 2004 - [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>

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/

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>

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

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.