tag:blogger.com,1999:blog-970055329001593038.post6576381724143042667..comments2024-03-26T03:40:08.295-07:00Comments on I Still Know What You Learned Last Summer: Git for researchersPhilhttp://www.blogger.com/profile/12760478278391942483noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-970055329001593038.post-12986192403571681692009-12-04T14:55:23.326-08:002009-12-04T14:55:23.326-08:00SVN can in principle support almost all of this wo...SVN can in principle support almost all of this workflow, but it's still more cumbersome to work with branches in SVN (better than it used to be, though). For example, in SVN, to see the full change history of a file that was merged, you have to look both on the trunk and in the corresponding branch directory. Not to mention, it's more complicated to create and keep track of branches in the first place than it is in git.<br /><br />Because of issues like this, people tend to not use the branching and merging features in SVN except for large and lengthy changes. So while you could use SVN, I think you would need quite a bit of discipline to get the advantages of a git workflow (e.g. being able to reproduce every state you've ever tested). I find git's basic model/workflow to be more elegant and better suited for this purpose.<br /><br />Regarding general VC habits: having distributed version control (git, hg, or bzr) solves a lot of the concurrency problems that tend to come up with CVS/SVN.<br /><br />For example, if you forget to sync before editing, it doesn't matter. You can commit as usual and as many times as you like to your local copy. When next you synchronize with the server, git incorporates the changes (usually 100% automatically). The local and remote changes are presented as two coherent and parallel lines of development that eventually get "sewn together" to form a state containing the changes from both lines. You don't have to worry about your local copy being sync'd up when you start work, it just gets fixed later.<br /><br />More generally, git also provides a number of features that help you fix up other things after the fact (like moving/copying patches around), so that even if you make a mistake (e.g. making a change on the wrong branch) it's easy to get yourself out of a jam. I find that makes it a lot less intimidating than RCS/CVS/SVN.Philhttps://www.blogger.com/profile/12760478278391942483noreply@blogger.comtag:blogger.com,1999:blog-970055329001593038.post-74582588084838311372009-12-03T08:22:38.326-08:002009-12-03T08:22:38.326-08:00Wow. This is a very thoughtful description of why ...Wow. This is a very thoughtful description of why version control is useful for research. Wish I had used git now. I often do the parameterize thing or comment out code alternatives thing.<br /><br />Though, I'm not sure what advantages git provides over svn. Should I really switch to git or mercurial?<br /><br />Also, sometimes, I'm not disciplined in my use of version control and I mess up. (Forget to sync before editing for example.)<br /><br />Pleaee enlighten me!Eugenehttps://www.blogger.com/profile/03371107097426938651noreply@blogger.com