distributed svn
2007-01-04-Thursday | Computer
So, Gnome finally abandon cvs. It was quite a few
years to late in my opinion. The good thing about
waiting is that it let the distributed revision
control system grow and become more stable/mature.
Yet, when gnome migrated, they choose to go with....
subversion... Why oh why? bazaar,
git or mercurial would all have been better, and
it would have given them the approval they need
to take over the world. We already know they CAN
do it. Personally, I'm a bazaar fan, but both
mercurial and git are really good and I think
that in the end, any of them are better than
subversion.
All isn't lost, there are ways to use DSCMs together with subversion.
SVK
from the svk web page:
svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.
I tried to use svk about a year ago, with very little success, but I've heard other people using it and being happy with it.
svk stores information about merging, etc in svn revision properties, so multiple people using svk can work together.
bzr-svn
Being a bzr fan, this is my favorite. One really cool thing about it is that it uses the same svn revision properties as svk, so you can use bzr, and someone else working in the same subversion repo, can use svk. This is really cool.
There are some problems with it, however. Currently, you must always get out the entire history from a svn branch. This takes time, and eats memory. For really large repositories, this is a show-stopper. I have tried to use it on repositories that have 35000 revisions, and it just doesn't work at all.
For smaller repositories, it's great!
git-svn
I personally haven't tried this one. It looks really cool, but I cannot find anything about how it stores merges within svn. From looking at the documentation, it looks like it simply doesn't at all.
It looks like git-svn is good only if you are working with it yourself and not in a team with other people. The other options seams better in that case. Please correct me if I'm wrong.
git-svn allows you to only get parts of a repository, which should mean that it works better on really large repositories, which might not be able to work with bzr-svn.
See this blog for more information on this, and this blog for more information on git-svn.
All isn't lost, there are ways to use DSCMs together with subversion.
SVK
from the svk web page:
svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.
I tried to use svk about a year ago, with very little success, but I've heard other people using it and being happy with it.
svk stores information about merging, etc in svn revision properties, so multiple people using svk can work together.
bzr-svn
Being a bzr fan, this is my favorite. One really cool thing about it is that it uses the same svn revision properties as svk, so you can use bzr, and someone else working in the same subversion repo, can use svk. This is really cool.
There are some problems with it, however. Currently, you must always get out the entire history from a svn branch. This takes time, and eats memory. For really large repositories, this is a show-stopper. I have tried to use it on repositories that have 35000 revisions, and it just doesn't work at all.
For smaller repositories, it's great!
git-svn
I personally haven't tried this one. It looks really cool, but I cannot find anything about how it stores merges within svn. From looking at the documentation, it looks like it simply doesn't at all.
It looks like git-svn is good only if you are working with it yourself and not in a team with other people. The other options seams better in that case. Please correct me if I'm wrong.
git-svn allows you to only get parts of a repository, which should mean that it works better on really large repositories, which might not be able to work with bzr-svn.
See this blog for more information on this, and this blog for more information on git-svn.
|