[Ilugc] Best version control mangement systems in LInux
- From: kapil@xxxxxxxxxxx (Kapil Hari Paranjape)
- Date: Fri Jun 6 21:25:23 2008
Hello,
VCS wars^Wdiscussions!
On Fri, 06 Jun 2008, Arnold Noronha wrote:
My personal preference is svn+svk.. so everybody is happy: those who
want centralized can use svn directly, and those who want
decentralized (like me) can use svk.
svk can get pretty slow once the number of commits becomes large. :(
I haven't worked with git or mtn or bazaar, so can't really compare.
I have worked with svn (in fact my Debian packages are in
svn.debian.org). However, of late, I have found the following
workflow using git and git-svn easier to handle.
0. I used git-svn _once_ to clone the repository from svn.debian.org
This takes a long time so it is best to do it once only!
1. I use git to do actual development work. This allows me to work on
topic branches merge etc. I have found git convenient even for
single-user work! (E.g. offline commits, colorized info screens)
2. I use git-svn to fetch/dcommit once I have a clean-ish branch that
needs to go to the repository.
3. I use "svn copy" to create new svn branches or svn tags.
I wish (3) could be avoided and git-svn would handle this too.
I believe this is easier than using svk with svn.
The reasons for using svn.debian.org instead of git.debian.org are that
I'm too lazy to migrate the existing repository which was created
when I learnt svn.
If one is starting a fresh repository then I would skip the svn part
altogether and just go with git.
Mercurial looks fine for this kind of work as well but there is no
hg-svn tool and tailor didn't work well enough for me.
In any case, you need to play a _lot_ (in a toy-mode) with a VCS
before adopting it.
It is best that you learn on a toy repository how to back out of bad
commits and messed up trees. Doing that on a live repository can be
nerve-wracking _and_ expose your ignorance to all those who look at
the history! In this too git is kinder than svn.
Regards,
Kapil.
--
Other related posts:
