A git-svn workflow

Git, the version control system, has a subversion integration feature.  In short, it allows you to use git to interact with a subversion repository: check out and commit code back to subversion.

It sounds like an excellent feature.  My first thought was that I’ll be able to make a subversion checkout on one host, and use git to propagate my changes throughout all other host I work on.  Finally, I thought I’d be able to merge changes back to where I did the subversion checkout, and commit my changes back to subversion.

However, there’s a problem with using multiple repositories, git merge and git svn. The most common way to move changes between git repositories is git push and git pull. In short, it does git fetch, and git merge (plus a bit of magic I’m not sure about).  If you use git pull/push and try to commit back to subversion, you will sooner or later fall into the trap that I fell into some time ago.  I’ve since worked out a relatively sane workflow which allows me to work with code on multiple hosts and send changes back to subversion with no horrible recurring code conflicts.

The executive summary is: Use “git fetch; git rebase origin/master” to propagate changes and format-patch + “git am” to propagate changes back to your root git repository (the one that was used to make the svn checkout).

host1> git svn clone http://example.com/foo foo
host2> git clone ssh://host:/home/joe/foo
host2> cd foo; edit files…
host2> git stage -p
host2> git commit
host2> git format-patch origin/master
host2> scp *.patch host1:
host1> cd foo
host1> git am ~/*.patch
host1> git svn dcommit
host1> some more work, commits, code incoming from subversion…
host1> git svn rebase
host2> cd foo
host2> git fetch
host2> git rebase origin/master

In this workflow, git pull and push are not used.

host1 → host2 [git rebase origin/master]
host2 → host1 [git format-patch; scp; git am]

You need to take care if you’re using things such as “git commit –amend” on host1 on commits that have been first made on another host (e.g. host2).  Otherwise, this workflow does not create any recurring conflicts.

A side note: it’s perfectly safe to branch and merge within one git repository.  The workflow described above deals with the problem of moving changes across multiple git repositories.


How do I install a Solaris package?

Shortly after joining a new team at work, I learned that team supports quite a number of machines running Solaris. While talking to the team about how the maintenance is done, the following question came up:

“How do I install packages?”
“You go to the server that keeps packages, you use ssh to copy the package in the directory format to the target machine, then you log into the target machine, and you run pkgadd.”
“No no, that’s not what I was asking. If I need to install a package on our servers, what do I do?”
“You use ssh to copy the package in directory format…”
“No no, not just one package on one server, I meant installing many packages on many servers.”
“You take the directory format package…”

It looked like I had an idea for a project: create a workable package management solution.  I ended up completing that project, which resulted in me being involved in the OpenCSW community. The general idea was like this:

  • There’s an internal mirror of the OpenCSW package archive.
  • An internal staging is implemented: we don’t install directly from the mirrored directory. Instead, copies called ‘unstable’, ‘testing’ and ‘stable’, are made.  Servers pull packages from ‘stable’ by default.  A chosen subset pulls packages from ‘unstable’ and ‘testing’.
  • There is an internal package overlay, containing additional, in-house built packages.  A wrapper around bldcat is used to create this repository. The same staging approach is used.
  • puppet is used to deploy packages.  pkgutil provider is responsible for interacting with pkgutil, which in turn is responsible for interacting with the Solaris pkgadd utility.  pkgutil is able to download packages from multiple package repositories.

If you want to know more or talk to project members, visit #opencsw on Freenode.