[LLVMdev] Version Control Upgrade?

[Michael McCracken]

On Mon, 10 Jan 2005 11:51:38 -0600 (CST), Chris Lattner
<sabre at nondot.org> wrote:
> 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.

I think this is a pretty important feature also, especially because
LLVM is a good platform for research, it is
particularly likely to have people using it as part of their own
projects while also wanting to
keep up to date and possibly contribute features back. 

This is what a distributed rev. control system gets you - for the CVS
mindset, this is essentially a way to create a branch without needing
write access to a central repository.

I've used arch to do this before - all I needed was read access to
someone else's archive and I had a branch.
>From then on I could keep track of local changes, changesets from
other people, and generate changesets to contribute that didn't
require my private changes.

I miss all this quite a bit for my current project, for which I'm
mucking about with LLVM a bit and I have no version control for my own
changes. There are ways to improve my situation, yes, but any solution
involves working around cvs's limitations and isn't terribly
satisfying.

For what my opinion is worth, I think it'd be a very smart move to
choose a distributed solution that lets people have private branches.

This being said, Arch is rapidly maturing, but isn't totally mature.
As of a few months ago, there were apparently still significant
problems using Arch on Windows. Also it's relatively obscure, and
requires some effort to start using.

-mike
 
> >> 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/
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


-- 
Michael McCracken
UCSD CSE PhD Student
San Diego Supercomputer Center
http://www.cse.ucsd.edu/~mmccrack/