One last entry on the topic of DVCS and repository management; I’m quite warming to the topic and the use of DVCS in general. So much so that I got a query on IRC the other day whether I was involved in the KDE transition to some other SCM system – and if Mercurial had been picked for that.

Well, “no” and “no”.

People who know all about this stuff are Thiago (for the Qt Software unit in Nokia) and the KDE Release Team and Dirk and Sebas. There’s a mailing list scm-interest (I think it’s called) for people who have a concrete dedication to improving the SCM for KDE. It’s not just about being interested, or indeed about having an opinion. Those who code decide, and there’s simply more engineering effort available for git than for anything else – unless someone pulls open a can of Mercurial developers, administrators and enthusiasts.

So I guess eventually I’ll have to become a git user as well, but right now I’ll continue to document my experiences with Mercurial. I hope that is vaguely useful to people who are sceptical (as I was) or worried about changes in workflow.

💔 The things I am working on right now are KDE4 packages for Solaris; S10U5 actually, SysV style packages based on RPM SPEC files (but heavily customized for Solaris, and fiddled around with because of our choice of toolchain). So I work on patches and specfiles, and sometimes – often, really – I need to test those changes under several architectures. At that point the ability to push changes from one repo to another one locally or on the local network without disturbing the public repositories is very valuable: I can hg push ssh://sparc/kde4-specs-dev to move my changes to the SPARC workstation and re-try them there. If you glance at the diagram you’ll see on the bottom row a box for each machine that I’m using locally. These machines have one or more repo and they push and pull amongst themselves to try out patches.

Once I’m satisfied about a patch – which might be a sequence of commits, so that’s a bunch of changesets – I push it to a “central” local devel repository on one of the machines.

During this process, if I get distracted I can always still clone another repo off of local devel, do a patch there and push it – but if I do that, I need to watch out with pulls and merges. That is something I’m not entirely comfortable with yet; SVN only confronts me with branches and merges if I ask for it. On the other hand, it’s nice that I can push a collection of changesets to local devel and that, thanks to the UUID on the changeset, the repositories all notice that it’s been applied upstream.

This process means that local devel can quite quickly accumulate lots of changesets which together represent one coherent change. The local master in the diagram, which gets changes only after ‘assemble and push’ from local devel, is the waypoint for changes where I clean up the history and sort out my thoughts a little. It’s a place for reflection and for merging whatever divergent developments have occurred during the day. After assembly a collection of changesets, now folded into one for the purpose of public presentation, gets pushed to my local master. And from there it finally goes public.

I have noticed quite quickly that skipping over a level and pushing directly to some repository “higher up” in the chain is just bad practice. It leads to lots of unneccesary merging and futzing about. And in the metaphors for DVCS development it kind of makes sense: you can’t skip from spring to fall (except in 1884) and you can’t change two lanes at once (unless you drive a Golf GTi).

Getting this discipline down and figuring out when to push and when to merge [[ segue into Kenny Rogers? ]] is, I think, the biggest change in workflow for me. Because it’s not a linear sequence of commits anymore, some things have to change – certainly when dealing with the later seasons where the pretence of linear changes is something you do want to keep up. But so far it really seems to be worth it.

The Wayback Machine did not archive the picture of repository layout, marked with 💔.