Developers’ Weblog

Sponsored by
HostEurope Logo

Developers’ Weblog

⚠ This page contains old, outdated, obsolete, … historic or WIP content! No warranties e.g. for correctness!

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

On modern VCSes

2014-01-02 by bsiegert@

There has been an ongoing discussion in the NetBSD community about migrating away from CVS (something that is not in question here, I know I know)—to the point that the tech-repository mailing list has been set up specifically for this discussion.

Eric S. Raymond recently posted an article titled "bzr is dying; Emacs needs to move" on emacs-devel. Thomas Klausner remarked that if you apply sed -e "s/emacs/NetBSD/g" -e "s/bzr/CVS/g" to the post, then the same applies, frighteningly accurate in fact:

In practice, I judge that sticking with CVS would have social and signaling effects damaging to NetBSD's prospects. Sticking to a moribund version-control system will compound and exacerbate the project's difficulty in attracting new talent.

The uncomfortable truth is that many younger hackers already think CVS is a dinosaur – difficult, bulky, armor-plated, and generally stuck in the last century. If we're going to fight off that image, we cannot afford to make or adhere to choices that further cast the project as crusty, insular, and backward-looking.

This is what I wrote in reply:

Scary how spot-on this is after the above substitution. I fully agree.

I know that this may spawn another centithread but: how about we use a "canary" for a VCS migration? For example, moving pkgsrc-wip to git would probably be trivial, considering that it's sourceforge that hosts it. Last time I checked, sourceforge supports hosted git repositories.

As a new data point, I did some hacking on pkgsrc on MirBSD during 30c3 using a clone of github.com/jsonn/pkgsrc. This was in part to work around the freeze, in part to see how git copes with the typical pkgsrc workflows. I was positively surprised, I must say. Some observations:

  • you want distfiles/ and packages/ in gitignore.
  • not ignoring work directories is actually a convenient way to find stale work directories quickly.
  • downgrading a single package (in my case, to get autoconf-2.61 for some configure script) is easy to do, using git checkout $revision devel/autoconf This set the working copy back to the given revision and put the changes to HEAD into the index.
  • branch/rebase/merge is a good workflow for upgrading single packages.

Thus, even if the NetBSD project is not prepared to move to git outright, we could do a move for pkgsrc-git, then pkgsrc. src could come later.

MirBSD Logo