tag:blogger.com,1999:blog-27488238.post7640234490196194840..comments2024-03-22T11:34:45.165+01:00Comments on taw's blog: Atomic Coding with Subversiontawhttp://www.blogger.com/profile/16972845140253292628noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-27488238.post-2450841304705766292007-07-18T10:30:00.000+02:002007-07-18T10:30:00.000+02:00I can think of better systems than our current ver...I can think of better systems than our current version control systems. Specifically I think an integrated VIM type system of undo/redo version control would be better. Namely there would be absolutely no commits. Or if there were commits they would be more like bookmarks. Instead the whole environment (editor+ide or whatever) would continuously be making a log of everything you do so that all changes could be undone or redone to any degree. The best type of system to accomplish this would be something with persistent storage like an image based system.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-88061901069328113882007-07-04T08:30:00.000+02:002007-07-04T08:30:00.000+02:00Subversion? Bleh.Try a distributed system like gi...Subversion? Bleh.<BR/><BR/>Try a distributed system like git, mercurial, or darcs... Then you'll experience the true potential of code management -- seamless branches, throwaway branches, merges which preserve history, ...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-75511795376812604292007-02-22T17:32:00.000+01:002007-02-22T17:32:00.000+01:00Good post.I can agree with atomic commits in some ...Good post.<BR/><BR/>I can agree with atomic commits in some occasions, but I usually prefer complete-and-tested-feature-commits, just because my team is not very small and because in our project usually the hurry-to-commit is a large source of bugs.<BR/><BR/>By the way, I don't mind grammar errors very much, just because my english is worse .. !!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-63191988404394314712007-02-22T00:47:00.000+01:002007-02-22T00:47:00.000+01:00I agree with your atomic commit opinion _completel...I agree with your atomic commit opinion _completely_ and that's in part because I follow that strategy religiously each day.<BR/><BR/>However, like others posting here, I have to let you know that your editing of this article is horrendous. You have more spelling and grammar errors that I can count... and that is really, really annoying, no matter how right you are about other things...Unknownhttps://www.blogger.com/profile/02006928619182786736noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-30920839588551269752007-02-21T22:55:00.000+01:002007-02-21T22:55:00.000+01:00George: My advice - if every commit requires "a co...George: My advice - if every commit requires "a code review, commit approval, mandatory lengthy test builds, regressions, etc.", and you cannot fix that (this sounds like a serious lack of trust issue), then just get yourself a local repository (or a branch in the central one) where you can commit whenever you feel like committing, use atomic coding there, and only do the paperwork on merging.<BR/><BR/>You're still going to lose productivity, only a lot less so.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-51181489259979083802007-02-21T22:46:00.000+01:002007-02-21T22:46:00.000+01:00It would only work in a very small team. Is a larg...It would only work in a very small team. Is a large team (for the sake of clarity, lets say more than five people) you do want to keep your commits as small as possible, but not smaller than required to fix a bug or to implement a small feature or a logically complete part of a larger feature. Plus, the time between commits will be mostly spent on following the process - code reviews, commit approvals, mandatory (sometimes very lengthy) test builds, regressions, etc.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-61200927212793358612007-02-21T21:37:00.000+01:002007-02-21T21:37:00.000+01:00svn is not that great... darcs' interactive patch ...svn is not that great... darcs' interactive patch recording is WAY better to create small, atomic patches.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-75197390008060775812007-02-21T21:07:00.000+01:002007-02-21T21:07:00.000+01:00I don't use subversion (I'm currently a darcs addi...I don't use subversion (I'm currently a darcs addict) but I sort of do "atomic commits" as you describe. The difference is I don't always commit right that second. I often do commit runs where I create 20 individual commits over my current directory in the space of 5 or 10 minutes.<BR/><BR/>But I definitely agree that an individual commit should be as small and atomic as possible.<BR/><BR/>What really helps is a script I wrote (and emacs integration) that lets me commit just part of a file. So if I'm working on a major feature and I happend to see an unrelated bug in the same file I can fix the bug and commit the change immediately without worrying about my half-implemented feature.<BR/><BR/><A HREF="http://porkrind.org/commit-patch/" REL="nofollow">http://porkrind.org/commit-patch/</A><BR/><BR/>I wrote a little tutorial for how it works here:<BR/><BR/><A HREF="http://porkrind.org/missives/commit-patch-managing-your-mess" REL="nofollow">http://porkrind.org/missives/commit-patch-managing-your-mess</A><BR/><BR/>Caveat: It doesn't support svn yet, but it does support cvs, darcs and mercurial so it should be easy to extend. I'll happily accept the patch to anyone who wants to add svn support.<BR/><BR/>-DavidAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-75793140867771409102007-02-21T21:05:00.000+01:002007-02-21T21:05:00.000+01:00Peter: Thanks. I need to script up some syntax san...Peter: Thanks. I need to script up some syntax sanity checker for Blogger, because Blogger software is not doing its job well enough.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-21711542670876548922007-02-21T20:27:00.000+01:002007-02-21T20:27:00.000+01:00You have a mismatched <code> tag after "When...You have a mismatched <code> tag after "When you do Atomic Coding"... Opera renders it funny.<BR/><BR/>When you do Atomic Coding, <code>svn revert<code><BR/><BR/>Should be:<BR/><BR/>When you do Atomic Coding, <code>svn revert<<STRONG>/</STRONG>code><BR/><BR/>Thought you might like to know. :)Anonymoushttps://www.blogger.com/profile/17231230372968631821noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-31244526614704599892007-02-21T19:32:00.000+01:002007-02-21T19:32:00.000+01:00Anonymous: Thanks for spotting the typo, I fixed i...Anonymous: Thanks for spotting the typo, I fixed it.<BR/><BR/>Anonymous: It cannot practically work like that, because you want to test your code before committing and you need to save the file to test it. But most editors can already do single-click SVN commits.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-91704748232859868442007-02-21T19:09:00.000+01:002007-02-21T19:09:00.000+01:00So the final logical step to this, and it is one t...So the final logical step to this, and it is one that I have been waiting for for years, is to have the "Save" function on your editor do an automatic commit, popping up ad dialog box that lets you enter an optional checkin comment.<BR/><BR/>- Elroy JetsonAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-29352970258845695502007-02-21T18:30:00.000+01:002007-02-21T18:30:00.000+01:00I agree with atomic commits 100%.BTW, you got "co"...I agree with atomic commits 100%.<BR/><BR/>BTW, you got "co" and "ci" mixed up in the following paragraph:<BR/><BR/>After you're done you can commit. svn co -m "Message" will commit all changes in current directory and its subdirectories. Very often you want to commit less than that, for example svn co -m "Some quick change in README" README while leaving rest of the code uncommitted.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-47421664632122706232007-02-21T15:51:00.000+01:002007-02-21T15:51:00.000+01:00My need to frequent (non-atomic) commits is to avo...My need to frequent (non-atomic) commits is to avoid merging with rest of the team. I've noticed that committing small pieces on highly concurrent environment (say >5 people) is preferable.Свилен Ивановhttps://www.blogger.com/profile/12452377116967812407noreply@blogger.com