[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