On 8/28/06, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
Where is The Truth? :-P
In the implementation. :) Something that could go wrong under CVS is that one file's commit would fail, the others would succeed, and the repository would be in an unexpected state. Smaller commits could be better, since it meant there was less that could go wrong. SVN uses atomic committs, so larger, multifile commits are not risky. It all succeeds, or it all fails. Under SVN, it's easy to roll things back to a particular commit, and to reference the changes by the revision number. So if we are implementing change XYZ, it's helpful to be able to say the change was implemented in r1234567. And if we decde to roll back, we have an implicit tag corresponding to the change. Under CVS, I don't think I ever actually "rolled back" a commit. It was too much work. Of I needed to undo something, I copy-and-pasted the code forward. Under SVN, I often rolled back commits that didn't work, by using SVN to copy forward the files that I want. (Not so much here, but at work.) Though, in either case, if the changes to the files are coupled, and we aren't talking about a humungous number of CVS files, I'd commit the changes together, for the same reason: "so it is clear what it is changed in that file and why it has been done." The evil practice is committing unrelated changes together, or mixing stylistic and functional changes in the same commit. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
