« Cluck - New Common Lisp Library | Main

Distributing Repositories

I've been using source control management (SCM) systems going back to the the very limited RCS back in the early 1990's. Over the years, I've migrated my SCM to take advantage of improved functionality. Recently, I migrated from subversion to git.

While I keep my home directory in SCM (initially CVS, then SVN, now GIT) and that directory is replicated across Linux, Windows, and Mac OS X systems, a big reason for changing from svn to git is to give people more access to my open-source projects.

Periodically, I'd have my CVS and SVN repositories available on a public web server. But, that typically required some effort of mine to mirror a public copy from my private repository. Using a distributed SCM like git, there is no additional effort needed to make a public copy of my respository. But, a bigger win over just making a public respository available is allow users to have their own local respository. While I appreciate the patches (bug fixes and improvments) users email to me, there are some cases where I feel the patch has limited value and don't incorporate it into my upstream respository. With a distributed SCM, users can maintain their own local patches while being able to merge changes that I make to the project's canonical repository. Though, I do hope users to continue to send patches that would be useful to a project's user base. As an added benefit, git has much improvement mechanisms for users to do so.

For my private use, the distributed repository system is not a big win. However, git has much improved branching over subversion which will help when I want to make a local branch for experimental changes.

To convert from my single private respository to a useful public git repository, I've separated my open-source projects into discrete git repositories. The histories of the git repositories on some projects go back to 2002. Unfortunately, I was not able to migrate my tags from subversion to git because git-svnimport got confused about the odd tagging/commits from the cvs2svn tool I used when I migrated from CVS to SVN. If checking out a particular old version is important, one can refer to the dates in the project's debian/changelog file to find the commit matching that release. At some point, I may write an automatic tool to retag the version numbers on the projects.

The public git repositories can be browsed at http://git.kpe.io/. I'm modifing my Lisp web site creation tool so it will automatically add the git repository to each project's website. For now, the typical URI to clone a git repository would in the form of git://git.kpe.io/<project>.git. I expect users of my projects will find the new, much deeper access to my open-source projects empowering.

The set of commands to clone the current set of open-source repositories are:
git clone git://git.kpe.io/cl-base64.git
git clone git://git.kpe.io/cl-modlisp.git
git clone git://git.kpe.io/cl-photo.git
git clone git://git.kpe.io/cl-readline.git
git clone git://git.kpe.io/cl-rss.git
git clone git://git.kpe.io/clsql.git
git clone git://git.kpe.io/cluck.git
git clone git://git.kpe.io/ctsim.git
git clone git://git.kpe.io/getopt.git
git clone git://git.kpe.io/hyperobject.git
git clone git://git.kpe.io/irc-logger.git
git clone git://git.kpe.io/kmrcl.git
git clone git://git.kpe.io/lml.git
git clone git://git.kpe.io/lml2.git
git clone git://git.kpe.io/md5.git
git clone git://git.kpe.io/pipes.git
git clone git://git.kpe.io/postoffice.git
git clone git://git.kpe.io/ptester.git
git clone git://git.kpe.io/pubmed.git
git clone git://git.kpe.io/puri.git
git clone git://git.kpe.io/reversi.git
git clone git://git.kpe.io/rlc.git
git clone git://git.kpe.io/rt.git
git clone git://git.kpe.io/uffi.git
git clone git://git.kpe.io/umlisp.git
git clone git://git.kpe.io/umlisp-orf.git
git clone git://git.kpe.io/vcs-tree.git
git clone git://git.kpe.io/wdq2wav.git
git clone git://git.kpe.io/wol.git
git clone git://git.kpe.io/xlunit.git
git clone git://git.kpe.io/xmlutils.git
git clone git://git.kpe.io/xptest.git

Comments (3)


git-svn does a far better job than git-svnimport.

Thanks a ton Kevin. I've made a lot of local changes to CLSQL to support new OODML stuff. I'm not sure whether you'll accept the patches to the mainstream repository but moving development to GIT will ease my headache of maintaining my local version.

Kevin Rosenberg:

You're welcome, Saurabh. I've sent you email about how I can best integrate your patches. And yes, empowering people's local changes (whether they wish to share their changes or not, or whether their submitted patches are accepted or not) is a big reason for me switching to a distributed system like git.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on September 5, 2007 1:17 PM.

The previous post in this blog was Cluck - New Common Lisp Library.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.