Re: The current hurd development system - or: optimizing for fun

[Alfred M\. Szmidt]

   >    Of course not change the VCS of a running project. But if we
   >    start from a mostly new codebase, using a better VCS would not
   >    be too much work.
   > 
   > That is quite a big `if', isn't it?

   right, but that's what we're considering, isn't it?

Are we? In either case, Savannah has support for GNU Arch now, so if a
new repository is needed there is no real problem in changing VCS's
for a new code base when such a code base exists.

   >    And no, you IMHO cannot realize -Ofun with cvs.
   > 
   > IMHO you can, and it has been achived quite often.  I guess it is
   > something we will have to agree to disagree about.

   OK.  Still I do not understand why so many projects use cvs.

And I don't understand why so many operating systems are built around
Unix.  It boils down to `worse is better' I guess.

   >    If nearly everyone can change code, it has to be possible to
   >    easily rollback the complete change of an
   >    unixperienced/malicious commiter.
   > 
   > CVS already allows for that.

   Maybye I am ill-informed, but AFAIK this is not really easy.

It isn't as easy as with changeset based VCSs, but it is easy enough.
Most of the time, the `incorrect code' is fixed by committing a new
changeset ontop of that.  Rolling back things isn't a very frequent
operation.

   >    I guess you only comment on the first statement. Commit rights
   >    aren't casted far and wide. Doing so would mean giving
   >    everyone the right to commit who wants to.
   > 
   > It might have to do with nobody contributing much code to warrant
   > them being given commit access.

   Maybye, but giving commit access _after_ the developer has
   contributed much code is completely against the Ofun paradigm.

Could you clarify why having commit access is a requirement for
actually starting to hack?  When I start, I just modify my local tree,
and work on that until I'm happy with the result.

Cheers.