llvm dev - May 2004 - [LLVMdev] Open Source Contributions (was Re: Benchmarks)

Chris Lattner wrote:
> On Wed, 5 May 2004, Vladimir Prus 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.
> >
> > There are a couple of problems. First, arch is not portable to
Windows.
> > Are you really sure nobody will port ALVA (or parts of it) to that
> > platform?
>
> Arch was just one example.  :)  I'm not familiar with Alva, what is it
> (google isn't particularly helpful)?
Actually, that's ALVA is what my spellchecker made from LLVM :-(. I meant:
if
LLVM is ported to Windows, then arch will become a problem.
> > Second, local repository is fine, but what if two persons ever decide
to
> > work on the same branch?
>
> I believe that arch allows you to do this kind of thing:
> http://www.gnu.org/software/gnu-arch/tutorial/shared-and-public-archives.ht
>ml#Shared_and_Public_Archives
Right, but you'd need HTTP/FTP server. Not a problem for *me*, but lots of 
folks are behind firewalls and can't do that.
> ... but again, I haven't really spent the time to look into revision
> control systems in any detail.
Ok.

- Volodya

On Wed, 5 May 2004, Vladimir Prus wrote:
> > > There are a couple of problems. First, arch is not portable to
Windows.
> > > Are you really sure nobody will port ALVA (or parts of it) to
that
> > > platform?
> >
> > Arch was just one example.  :)  I'm not familiar with Alva, what
is it
> > (google isn't particularly helpful)?
>
> Actually, that's ALVA is what my spellchecker made from LLVM :-(.
Whoa.  :)
> I meant: if LLVM is ported to Windows, then arch will become a problem.
Excellent point.  Windows compatibility is a must.
> > > Second, local repository is fine, but what if two persons ever
decide to
> > > work on the same branch?
> >
> > I believe that arch allows you to do this kind of thing:
> >
http://www.gnu.org/software/gnu-arch/tutorial/shared-and-public-archives.ht
> >ml#Shared_and_Public_Archives
>
> Right, but you'd need HTTP/FTP server. Not a problem for *me*, but lots
of
> folks are behind firewalls and can't do that.
Sure.  I can't imagine that there is a wonderful solution other than this
though.  In particular, how can you do distributed development without it?
The whole idea is to reduce the need for a completely centralized
development model.  Ideally, the UIUC servers would just be the
"official"
tree: lots of development could happen publically in trees that are not on
our servers.  When the development is done, or in a good state, it could
be merged into the official tree, and be released in the standard
releases.

I don't know if there is any ideal tool available today that satisfies
these goals, but it is my personal ideal in a source-control system.
(Assuming that you can revision directories, have atomic commits, and all
of the other things that CVS doesn't ;-)

The only two systems that I'm familiar with that support this kind of
development are Arch (not available under windows?) and Bitkeeper (many
licencing restrictions).  I don't think that subversion supports the
features above, but again, I really have little idea of what I'm talking
about.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Chris Lattner wrote:
> > Right, but you'd need HTTP/FTP server. Not a problem for *me*, but
lots
> > of folks are behind firewalls and can't do that.
>
> Sure.  I can't imagine that there is a wonderful solution other than
this
> though.  In particular, how can you do distributed development without it?
> The whole idea is to reduce the need for a completely centralized
> development model.  Ideally, the UIUC servers would just be the
"official"
> tree: lots of development could happen publically in trees that are not on
> our servers.  When the development is done, or in a good state, it could
> be merged into the official tree, and be released in the standard
> releases.
Why do you really need distributed development? The possible problems with 
centralized development are
1. The server might be often down.
2. There's too much number of active branches, so nobody understand
what's
going on.
3. You can't commit while you're on a plane.

I don't think first two points are that important, and I never being on a 
plane so can't comment on the third.

Ok, anyway, you decide.

- Volodya