On Sat, Jul 19, 2008 at 05:46:47PM -0700, Andrew Lentvorski wrote:
Even if the "repository version number" is 189--each individual file has its own version number. So, file1.c is number 89, file2.c is number 110, file3.c is number 146, and only file4.c which you just touched has a version number of 189. Consequently, you can get a commit that fails in SVN and yet some of the files had their version numbers updated. Very annoying to unwind.
Is it really, seriously is that stupidly designed? No wonder people comment out blocks of code if you can't do something as simple as reverting an old change. If I have a bad commit in git, and I've pushed it out (so that I can't just edit my local history), I can revert it merely by saying: git revert commit-id This works, even if the commit is old, although the older it is, the more likely there are to be conflicts to resolve. Or, are you describing something even worse, that if something goes wrong in the middle of the commit, SVN leaves things in a mangled state where some of the files you gave it get updated and some don't? I thought this level of atomicity was one of the design goals of SVN. I've watched people try and revert changes in P4, and it is amazingly convoluted. Most seem to give up if you ask them to revert something other than the most recent change made. Thanks for removing the last respect I had for SVN. David -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
