> 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.
>
Wow, this is probably my second most favorite feature of SVN (proper history of moved/renamed files is first). Just to refute your example (let alone all the other arguments I could make FOR needing atomic commits), I work with a medium sized code-base (roughly 1 million lines of code). I can't tell you how many times lack of atomic commits (we use CVS) have hosed someone up and wasted countless hours of developer time. You make it sound like finding an issue related to a non-atomic commit is easy to track down (as you say "When I do an update and it breaks, I do another update."). I'll tell you that in a lot of cases, especially in large systems, it is NOT easy to track down. It does not always manifest itself in broken builds, it does often manifest itself in subtle run-time errors.
I would be willing to bet that a majority of the SVN crowd *need* atomic commits, some don't even realize they need it! ;-)
That said, it would be cool to move a repository the way you suggest, but your arguments for such a feature are in need of some rational thought!
Cheers,
Craig
---------------------------------------------------------------------
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:36:49 2003