開発
Versioning
denvazh
Almost a year ago I wrote a small post about three versioning system I’ve used so far: CVS, SVN, GIT. Note, that I mentioned them in the order of appearance. Nowadays, cvs is almost in deprecated state, svn is widely used, however git is entering our life (by “our” I mean software developers) very fast. For example, latest XCode published by Apple have native support for both svn and git. They clearly have their own benefits and drawbacks and there are many books written about it (actually both of them have good documentation), so I would mainly concentrate on my thoughts and tastes.
Everyone has its own set of requirements for any tool one’s using. In my case, I have different approach for projects where you work in groups and own projects, which you work on locally. For the latest, I think git is clearly more convenient to use, because you do not generally need to synchronize every piece of code with a main repository. On the other hand, if in the project development are involved certain number of people and you would clearly want to have centralized storage and management of the code. This is mainly due to a number of developments tools that support svn.
In my case, I used svn (and still use), when I work with GUI-based IDE (netbeans, eclipse, xcode), and recently I was curious enough to try git for command-line scripts I write on the server side. In this sense, git proved to be very easy to install (I actually prefer to use compile from source and then put it in the home folder with necessary pathes for binaries and man pages), and has very comprehensive documentation, which shows common points and difference with/from SVN, so its virtually enough to get started.
After a while I was able to configure vim with git, so I could commit without even leaving vim, which I find very good way to organize shell scripting (note: fyi, there is a github repository which has quite a lot of plugins for vim here and its possible to write a script, that would actually pull all recent updates automatically).
When I started writing such script I found quite interesting feature in git I haven’t seen in other versioning systems: git-submodule. From the documentation: Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit. They are not to be confused with remotes, which are meant mainly for branches of the same project; submodules are meant for different projects you would like to make part of your source tree, while the history of the two projects still stays completely independent and you cannot modify the contents of the submodule from within the main project.
This is quite interesting, because it allows to store totally foreign projects along with your own. So, I think in the future posts about versioning I will actually add some examples I’ve created so far and show some interesting stuff, that git actually allows to do.