History of CVS Migration

Comparing versions
Version 11Current version
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 super modules
Keywords" keyword substitution is just stupid" - Linus in his trademark @$$hole attitude. Do some scripty stuff is his answer. And that is the _right_ answer since it is a huge cause of merge pain while developing. Keywords should be set at release time, not during development. I will develop a release script that handles this for us. -waterdrgonKeyword 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. CentOS 5.4+ broke things so the rpm would not build - had to docbook dtd definition to get a Fedora rpm to build properly.
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 http://stackoverflow.com/questions/12843/how-to-combine-two-projects-in-mercurial



 
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



Page History
Date/CommentUserIPVersion
17 Jun 2010 (22:37 UTC)
spiderr71.70.210.9126
Current • Source
spiderr71.70.210.9125
View • Compare • Difference • Source
spiderr71.70.210.9124
View • Compare • Difference • Source
spiderr71.70.210.9123
View • Compare • Difference • Source
Will69.203.72.16122
View • Compare • Difference • Source
Will69.203.72.16121
View • Compare • Difference • Source
spiderr24.171.168.22319
View • Compare • Difference • Source
Lester Caine81.138.11.13618
View • Compare • Difference • Source
spiderr71.70.210.9117
View • Compare • Difference • Source
spiderr71.70.210.9116
View • Compare • Difference • Source
WaterDragon130.37.29.8015
View • Compare • Difference • Source
WaterDragon130.37.29.8014
View • Compare • Difference • Source
spiderr70.154.110.15712
View • Compare • Difference • Source
spiderr70.154.110.15711
View • Compare • Difference • Source
WaterDragon82.171.181.20810
View • Compare • Difference • Source
WaterDragon82.171.181.2089
View • Compare • Difference • Source
spiderr71.70.210.918
View • Compare • Difference • Source
spiderr71.70.210.917
View • Compare • Difference • Source
spiderr71.70.210.915
View • Compare • Difference • Source
spiderr71.70.210.914
View • Compare • Difference • Source
spiderr71.70.210.913
View • Compare • Difference • Source
spiderr71.70.210.912
View • Compare • Difference • Source
spiderr71.70.210.911
View • Compare • Difference • Source