On Monday 08 December 2003 22:02, Aaron Optimizer Digulla wrote:
>> On Mon, Dec 08, 2003 at 09:06:46PM +0100, Branko ??ibej wrote:
[snip]
> Well, does this matter? I mean how many developers actually *need* atomic
> commits? Or to put this another way: How big a problem is this? When
> I do an update and it breaks, I do another update. That's not much
> effort.
Sometimes a commit does not goes as planned due to unforseen events, like a
hard disk crash or loss of network connection. This leaves the repository
with a random collection of committed files unless you have atomic commits,
and anyone doing an update before the repository is cleaned up will have some
merry time. I look upon atomic commits as a kind of an insurance : mostly you
don't need it, until you really need it, but then it's to late.
> > Show me one solution to CVS's server process leaving locks in the
> > repository (apart from the "admin goes and removes the lock files by
> > hand", or the next step, "cron removes CVS lock files").
>
> Well, when something's wrong with CVS, I can use vi and rm to fix it.
> When I started to use svn (0.23, I think), it corrupted the database
> four times until I realized that I should not press Ctrl-C on Windows
> while it does a checkout. That's bad.
>
> From here, svn has many neat features (most of which are interesting
> from a theoretical point of view) but it has some big flaws and the
> biggest of them is the stability of the data underneath. I mean:
> The whole point of all this is that it should be impossible to
> loose data.
It's always possible to loose data, and that's one good reason to have
backups. Manually editing a CVS repository due to a failed commit is one easy
way to loose something valuable.
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 8 23:21:50 2003