Cosa significa per commit atomico per un sistema di controllo delle versioni?

Significa che quando si esegue un commit sul sistema di controllo della versione, tutto ciò che si vuole commettere va in, OPPURE niente.

In CVS, quando si tenta di eseguire il commit è possibile che il commit abbia successo su diversi file, quindi fallire su molti altri (perché sono stati modificati). Questo lascia il repository in uno stato sfortunato perché metà del tuo commit non è presente, ed è probabile che tu abbia lasciato le cose in uno stato in cui non verranno compilate o peggiori. Ora devi sbrigarti e integrare le modifiche in modo che tu possa impegnare gli altri file prima che qualcun altro debba aggiornarsi e ottenere il set di modifiche non funzionante.

In SVN questo non succederà - SVN commetterà tutto ciò che hai cambiato, o fallirà l'intero changeset. Pertanto, non lascerai mai il repository in uno stato di errore a causa di problemi di commit.

Questo è spiegato ad esempio in ciao-ciao CVS. Sono stato sottoposto a Subversed articolo scritto da Andy Lester :

If I try to commit in Subversion, but one of the files has a conflict, or is out-of-date, none of the files commits. In CVS, you’ve got a half-commited set of files that you have to fix RIGHT NOW.

Il fatto che CVS costringa il programmatore a risolvere immediatamente l'unione è controproducente. Rispetto a questo, un'opzione per ritardare / annullare / fondere attentamente le modifiche è un vantaggio sostanziale.

Altri vantaggi di SVN su CVS spiegati nell'articolo precedente sono:

• Local versions of everything you do
   
  If you want to cvs diff, you have to be able to connect to your repository. No net connection, no diffing. Subversion stores local pristine copies of what you’re working on, so svn diff will work just fine. Want to start over? svn revert works unconnected, too.

• Symbolic names of revisions
   
  HEAD is the name of the tip of the trunk in CVS, but I’ve always wanted to be able to say “-r-1″ like I could way back when in PVCS days. With CVS, I have to do a cvs log on what I’m editing, and then subtract one. That’s no fun. With Subversion, I can say svn diff -r PREV.

• Real status reporting
   
  In CVS, the only way you can see if something on the server is newer is to cvs update and hope that whatever comes down doesn’t cause any conflicts. With the svn status command, I get real status, so I can see if there are conflicts BEFORE I do an update.

• Helpful handling of merge conflicts
   
  In CVS, if there are conflicts, you get conflict markers in your file. In Subversion, you get conflict markers, PLUS a copy of your original, pre-conflict file, PLUS the version that came down from the server, PLUS the version that you were originally editing. Then, you must explicitly svn resolve filename.txt to tell Subversion that you’ve fixed the problem. No more accidentally commiting back into CVS with conflict markers still there.

Significa che tutte le modifiche a tutti i file sono impegnate in una singola transazione, quindi o tutte hanno esito positivo o nessuna.

Questo significa che è meno probabile che le modifiche parziali vengano registrate nel repository che causano il fallimento delle build. Puoi ancora convincere le persone a dimenticare di archiviare tutti i file pertinenti, ma questo è un problema di processo piuttosto che un problema con il sistema di controllo delle versioni.