[LLVMdev] Version Control Upgrade?

[Reid Spencer]

On Mon, 2005-01-10 at 09:29, John Criswell wrote:
> Reid Spencer wrote:
> > 
> > 3. CVS doesn't have atomic commits or the notion of a change set. This
> > has bitten me several times when I'm doing a large commit .. users
> > update and get .h files out of sync with .cpp files or other
> > inconsistencies. That never happens with the tools that support atomic
> > commit (most of them).
> 
> Okay.  I guess this is happening because our CVS server is much slower 
> for you than it is for me, which is why I never have this problem.  So 
> this is more important than I thought.

Yeah, not everyone's on your high-speed network.  At some point the
non-UIUC developers will out number the UIUC ones. Network efficiency
and scalability will become very important because data will be coming
from all over the world. We already have patches being submitted from
Germany, Russia, Japan, and probably a few other places I'm not aware
of.

> > 
> > 4. As you mentioned, file & directory copy/move aren't supported in CVS.
> > This is a pain at times as I have to contact someone at UIUC to "copy
> > the ,v file". This bit me over the holidays as no one at UIUC was
> > available for a day or two.  I'm sure you'd all rather not have to deal
> > with such requests. Chris ends up taking the brunt of these requests.
> > Many of the other tools support moving and copying files around.
> 
> Agreed.  This is a pain, and I forgot that you can't just move stuff 
> around like we can here.

Yup.

> 
> > 
> > 5. CVS doesn't support distributed development well.
> 
> How important do you (and others) feel this feature is?

Right now, its probably not a big deal. When we have significantly more
developers it will become crucial. Not only will it scale better but it
will actually let remote developers be more productive than they can
with a centralized server. I travel on planes a lot and would *LOVE* to
take a copy of the repository with me when I do.

> > 
> > 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 do. As the number of developers grow we'll want to control who has
write access where so that the *developers* can feel safe about what
they can change and what they can't. See Morten's response for a case in
point.
 
> 
> > 
> > 7. Authentication. CVS passwords are notoriously easy to crack and
> > shipped over the net in plaintext when using pserver. Using SSH would
> > help but that means giving every developer a login account on the CVS
> > server. I'm sure UIUC doesn't want to do that. I'm not sure about the
> > others but Subversion handles this really well via that WebDAV
> > (Distributed Authoring and Versioning) Apache plug-in. All requests go
> > via HTTP and the web servers authorization and authentication mechanisms
> > can be used. This also helps with getting around firewalls.
> 
> So far this hasn't posed a serious problem, but as we get more external 
> developers, it will.  And the firewall note is also a good point.

Yup. Its not a big deal right now because we're all a friendly bunch and
the community is relatively small. As our numbers start to grow, LLVM
gets a following, and we get more notoriety, there will definitely be
some problems in this area. We can't just trust everyone on the planet
to be good net citizens. Look at what happened to GNU's web site when
they were cracked .. took them months to get it sorted out.

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/20050110/743e5ad0/attachment.sig>