svn vs hg

Hello all,

I had a good chat this morning with several of the members of this group about integrating and aligning the work I've been doing in the CSS wg on our testing tools with the efforts of this group.

I think the CSS wg has a good start on our testing tools and I look forward to working with you to develop a strong set of tools that can be used by the whole W3C.

We already have a somewhat mature test harness (test runner in your nomenclature) and a good start on test suite building tools. The next major system that I'm beginning to work on is our test suite management system (code named "Shepherd").

Shepherd is designed to be a web interface tightly integrated with our test suite repository. It'll facilitate reviewing, approving, and bug tracking of the test files as well as adding a query and editing system for the test case metadata. There are plans to also allow some degree of direct creation and editing of the tests in the web ui. It will also manage the layout of the test source files within the repository and integrate with our build system.

My current dilemma is the choice of source repository used for the test suite. We've been using svn and I understand that this group has decided to use hg.

I'm not trying to restart a whole svn vs hg debate here, but it would be very helpful for me to understand the reasons that this group has decided to use a distributed vcs vs a centrally managed one.

Our reasons for choosing svn are that it's simpler for non-geeks to learn and understand (many of test authors fall into this category), and that a centrally managed repository fits nicely with our philosophy of test suite development. To that end, Shepherd was designed from the ground up to live on top of a svn repository.

Now, I certainly see the advantages to aligning the test suite tools on a common technology infrastructure. And Shepherd is early enough in the development stages that it'll be much easier for me to switch to hg now than down the road some time. So far, I'm not seeing any reasons why hg wouldn't work for our system, but it'd still have to have the notion of a central authoritative repository with a given directory structure and several policies enforced throughout the repository (like naming conventions, avoiding naming collisions, meta data handling, etc). These policies will be enforced by commit (or push) hooks on the authoritative server.

What I'm trying get at here is why hg was chosen. Was it just because it's the vcs flavor of the month, seen as more modern, etc or was there some kind of practical need for a distributed vcs and if so, does that imply a usage pattern that is fundamentally incompatible with our Shepherd system and suite management philosophy?

If Shepherd and hg can play nice, then I'm ok with convincing the CSS wg that we need to switch to hg and building our tools around that (but if I'm going to do that, I need to make that call now). If there's some need for a distributed vcs that just doesn't work with our test suite management philosophy, then we're probably just going to stick with svn. (There are also techniques for integrating hg client repos with a central svn repository, perhaps that might be a workable solution as well...)

Peter

Received on Monday, 9 May 2011 21:31:13 UTC