CVS Migration

Moving from CVS with extensive virtual modules (aliases) to Git or Mercurial

Created by: spiderr, Last modification: 17 Jun 2010 (22:37 UTC)
This is the notes about the bitweaver.org projects migration from CVS which makes extensive use of virtual modules (aka aliases ) in CVS to a distributed version control system (VCS) such as Mercurial or Git.
A Simple Table
Feature Git Mercurial
Ad-hoc BuildsAs of git 1.5.3, there is a concept known as submodules The subgit script wrapper is available.Mercurial has subrepos that support multiple VCS systems including CVS, subversion, and git. The subhg script wrapper is available.
Keywords" keyword substitution is just stupid" - Linus in his trademark @$$hole attitude. Do some scripty stuff is his answer. No SCM support during build/export for tagging files with a release marker. /nickpalmer will develop a release script that handles this for us. The reason it might be regarded is stupid is that you can track every tag and branch to a SHA id, providing precise knowledge of the state of the code for a release (assuming one might use a tag for a release). Consider how jquery uses tags on github to denote release versions.Keyword Extension works like a charm. Supports all existing CVS keywords out of the box.
Cross Platform SupportWindows support is reported to be weak, but reports were two years ago and much progress has been made. It is "good enough" with msysgit to get the job done.Rockin' on all platforms - linux, windows, OSX
BuildOn CentOS, git needed to be upgraded to get super modules. The FC13 git-1.7 rpm worked (rpm -ivh --nomd5). One small git.spec tweak was removing the conditional "--vendor" around desktop-file-install, so the line looked just like: "desktop-file-install --vendor fedora --dir=%{buildroot}%{_datadir}/applications %{SOURCE4}" CentOS 5.4+ broke things so the rpm would not build - had to edit docbook dtd definition to get a Fedora rpm to build properly. Replace "4.5" with "4.2" in /etc/asciidoc/docbook.confMecurial support is available from the package manager on most distros
Windows InstallationThe reference for installation of git on windows is msysgit but so far attempts to get TortoiseGit working with that have not been successful.TortoiseHg provides a complete installation in a single package. TortoiseHg is also available on linux for users needing cross OS support.
MigrationMigration with cvs2git is a snap with the attached "convert" script:
. Note that the script expects the repository to be stored in /cvsroot/bitweaver -Waterdragon
#Migrate each module separately, and then combine
CIA/IRC notificationsThere are three scrips - ciabot.pl which is old, ciabot.sh which is configuration free, and ciabot.py which is fast. For the central repo, the following like should be added to foo.git/hooks/update (one line is broken here simply for formatting of his comparison table):

/home/git/ciabot.py ${refname} \
$(git rev-list ${oldrev}..${newrev} | tac)
hgcia extension is painless and can easily support local repo's



Related Items

Packages » Unmaintained Packages

These packages are no longer maintained and are not supported any longer.

  •    •    •    •    •    •    •    •    •    •  

Comments

Priority ? Discussions ?

by Tochinet, 09 Jun 2010 (10:59 UTC)
Hi,

I realise I may become inpopular with this post, or look like someone that meddles into other's business, but could you tell the audience why this is now your priority ?

I can understand that the sourceforge developer's list is full of SPAM, and that the many aliases is some issue. But don't you think that there are more important developments to make prior to moving around the code ?

I'd really rather see more effort spent on the internal documentation of 2.7, in order to make bw more attractive for (new) candidate users/administrators. I'm willing to contribute to that to some extent, assuming the necessary support.

So please take a bit of time to explain why this migration is important for the future of bitweaver. I didn't see any discussion about it (but maybe developers already left sourceforge as well ?), and from the outside this looks more an internal (tool) change only relevant for developers (since the current CVS seems to work) but that requires a lot of efforts.

Actually, leaving sourceforge for some more confidential repository could have a negative impact on bw's image/brand. There must be other ways to solve that spam issue, or not ?

Re: Priority ? Discussions ?

by spiderr, 10 Jun 2010 (04:50 UTC)
Tochinet,

I see lester and WaterDragon chimed in with technical reasons. I do want to say I appreciate your challenging questions.

We will likely have our repository mirrored, to either http://github.com/ or http://bitkeeper.com/ which will be just as beneficial as sourceforge, which has honestly been going downhill for years.

Git is probably preferred, however it has many challenging issues to fit into our highly modular code organization.

Ease of support

by Lester Caine, 09 Jun 2010 (11:55 UTC)
Tochinet - what you are saying is quite correct, but problems with sourceforge go back many years, sometimes when I am trying to sync it is busy doing housekeeping because the US are fast asleep, and THEIR unilateral decisions on new ways of working have alienated many projects. A number of projects I am involved with have now moved off.

The debate on IRC over which repository service to move TO is just as heated, but to be honest, I don't think it matters since the new DCVS repo's can simply be cloned to a number of sites for visability!

Migration will basically remove a hassle that we have been putting up with for some time, and allow many of us to get back to the more useful development work.

Yes, a big priority

by WaterDragon, 09 Jun 2010 (23:12 UTC)
This has less to do with sourceforge and more to do with moving to tools that can work better for the developers, though the benefits of getting off sourceforge are many.

In truth CVS does NOT work, though it may seem that it does. Merging and merge management is so painful with CVS that we simply do not branch. Since bitweaver developers have many different requirements this often leads to forks of packages.

Because CVS is so bad at handling branching and merging, good work done in such forks often does not make it back into the core of bitweaver. This in turn slows down improvements for general users of bitweaver and frustrates developers.

Lester is exactly correct that the effort being made to move OFF of CVS is being done to allow us to do the business of development using a more modern tool-set. We anticipate such efforts will be better for everybody in the bitweaver community.