version control and LIP

[Seth Kurtzberg]

I did some further reading, and it does appear (to me at least) that 
there is a lot of overlap conceptually between darcs and arch.  Not in 
terms of implementation, but in terms of goals.

An interesting problem is thus:  how to we support darcs without mucking 
up the works for CVS (& co.) users, and v.v.

Seth

Ketil Malde wrote:

>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 :-)
>  
>