[darcs-users] CVS-style development with darcs

Samuel A. Falvo II sam.falvo at falvotech.com
Fri Jul 2 01:52:13 UTC 2004


On Thursday 01 July 2004 12:02 pm, Juliusz Chroboczek wrote:
> There is no way you can ever lose data that has been committed without
> doing manual surgery on /var/cvs/.  This gives you a peace of mind
> that is difficult to understand if you haven't been exposed to CVS.

Explain that to myself and so many others who worked at Hifn, Inc., where 
an aborted commit (for any reason what-so-ever) more than likely broke 
the repository, which *required* hand-editing /var/cvs on the remote 
repository server.  And yes, data was sometimes lost when doing this.  
As a result, people have developed scripts to invoke check-ins twice 
(some paranoid people did it three times).

And of course the myriad of times when a "successful" CVS checkout or 
checkin (without the aide of cvs edit) seemingly randomly left lock file 
droppings all over the place, leaving tens of people in a department 
unable to commit changes to files.

I swear that 50% of the calls I made to the sysadmin group at Hifn were 
to request lock files to be removed.

In my personal experience, and the experiences of others seem to 
corraborate this, CVS is a great tool, and it fills a real need; 
however, it is not safe.  It has absolutely no ACID-properties 
what-so-ever in a real-world, industrial production environment.  This 
is a known problem, and is addressed by Subversion.

To date, I haven't used SVN, but I'd like to see a comparison, especially 
in light of this document, on how darcs compares with SVN.

> Darcs, on the other hand, doesn't enforce any invariants except from
> honouring patch dependencies.  Patches flow randomly between repos,
> and it takes a lot of discipline to ensure they flow the way you want
> them to.

I think we're comparing apples to oranges here.  Darcs also will happily 
refuse to accept a check-in unless user-supplied test scripts all pass 
to completion.  This can be used to enforce invariants about the program 
that CVS simply cannot.

Finally, patch flow problems are totally unrelated to server database 
safety.  I really don't see the correlation at all.

> I think the right design is not to forbid individual flows, but to
> have _darcs/level, an integer, and forbidding patches from flowing
> from a lower-level to a higher-level repo (think water); then I could
> setup stable to have level -1, and all'd be fine.  Again, any ideas
> are welcome.

But -1 is lower than 0 -- wouldn't that mean changes made to stable 
wouldn't make it into development releases?  That makes no sense to me.  
In the case where you have precisely one waterfall of development, sure.  
But if you have, say, three different waterfalls, all leading to the 
same stable tree, then this is counter-intuitive.  How would you handle 
the case where a change in waterfall A needs to be reflected in B and C 
as well?  I would like some means of back-propegation too.

--
Samuel A. Falvo II





More information about the darcs-users mailing list