On 14/01/07, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
On 1/13/07, Ira Abramov <[EMAIL PROTECTED]> wrote: > Quoting Amos Shapira, from the post of Wed, 10 Jan: > > On 10/01/07, Ira Abramov <[EMAIL PROTECTED]> wrote: > > > > > >every few hours I try cvs update and building again. funny stuff. it's > > >always in flux, people commit to it around the clock, dependencies > > >appear and go away... just like the code here at work :-) > > > > That's probably the prime reason why I despise CVS and much prefer SVN and > > P4 - atomic commits (and easier merges, and file renaming, and...). > > what has this got to do with anything? if they have a commit done every > hour or two and I do svn update or cvs update? > Doing cvs update in the middle of somebody's big commit, you risk getting an inconsistent state. With a project having such frequent commits, this risk is non-negligible.
And there is no way for you to tell that you checked out in the middle of a "big commit" or not. With svn, you always get either the state before the whole commit or
after it, no problem.
On top of that, or adding another view point to the same theme - look at things from the other side (the side of the people who commit changes) - the person doing the commit can't tell for sure whether the merge of all the files is going to result in a working version. If he finds that he has to stop the commit to fix a merge problem you are still stuck with the new version of the files he already finished with in this "commit cycle". With SVN you can: 1. Stop the commit in the middle and revert to the state of the repository before the cycle began (because the entire commit - file changes, file moves, directory creations, whatever - is viewed as a single, atomic, operation). 2. It's easier to create/update/merge branches so you (the person doing commits) can do the merges in your own private branch before merging that branch into the HEAD version. --Amos
