version control and LIP

[Ketil Malde]

Sven Panne <Sven.Panne at aedion.de> writes:

> Very true. I'm not against anything new when it really solves a problem,
> but I'm strictly against something simply *because* it's new. 

"There are two kinds of fool: one who says this is old, and therefore
 good, and one who says this is new, and therefore better."

> I've seen quite a few baroque VC and build systems in companies
> which no one could understand as whole, because so many tools were
> involved

I'm not sure this applies to the discussion, whether you use Arch,
Darcs, or Subversion, they are all fairly self contained, independent
of surrounding tools, and from what I've seen of them, at least as
easy to understand as CVS.   

I'd be more worried about robustness and maturity.

> bit of sh could have done the jobs easily. So what I'm proposing is:
> "Keep it simple." And CVS *is* simple, we all use it daily...

CVS may be simple for you if you use it daily.  Some things are
unnecessarily complicated, though: moving/renaming, branching,
and merging, to mention a few.  CVS is also has a bit of a threshold
for contributions from "casual" users.

> What I'd like to hear is the set of needs we have, and if we really agree
> on them. For my part, I'm quite happy with the development models supported
> by CVS/Subversion, but there are surely other opinions. After we've reached
> a conclusion on our needs and goals, we should look for a technical solution,
> not the other way round.

I've been using Subversion a bit, and am generally happy with it.  It
does branching neatly, but merging is a bit painful still, and
requires the user to work out exactly which versions the changes he
wants to merge occurred between.  Move/rename is better than CVS, but
tends to clutter the history a bit.  And, I almost forgot, it lets you
do a lot more operations locally than CVS, without needing online
access to the repo.

What's great about Darcs is that the threshold for new users to submit
patches is very low, if I 'get' the LIP repo and fix a bug, it's very
easy for me to 'push' that change (and only that one); the patch will
get mailed back to the repository address, where an official
maintainer can apply and test it before he integrates it into the
official repo.  No need to have any special commit access.  And of
course it's distributed, so it lets individual developers 'pull'
patches from each other's repositories/working directories without
involving any central repository.  

-kzm 
(I've got a loaded tomato here, and I'm not afraid to use it :-)
-- 
If I haven't seen further, it is by standing in the footprints of giants