Re: svn vs hg

On Mon, 9 May 2011, Linss, Peter wrote:

> 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.

That sounds interesting. Are there details anywhere? How tied is it to 
CSS-specific assumptions (one tets per file, metadata embedded in the 
test, etc.)

> 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.

Fundamentally a testsuite that is being developed and used by a number of 
participants is a distributed system. Having a centralised version control 
system doesn't make any sense. For example it is likely that every browser 
vendor that runs the tests will want to add local patches to their local 
copy of the repository e.g. in order to make result reporting work 
with their specific test harnessses. Having to maintain these patches by 
hand is relatively lots of effort; putting them on a branch in the 
vendor-local clone and merging upstream changes onto that branch is a 
relatively straightforward way to solve the problem.

Vendors and individuals may also want to develop outgoing tests with all 
the benefits of using a VCS internally before pushing to the wider world.
This might not be critical when developing a small number of individual 
tests but becomes critical when developing larger testsuites for complex 
features.

> 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.

There is nothing about using a DVCS that implies there can't be a 
particular clone that is treated as canonical for a given purpose. It is 
reasonable to assume that the clone on dvcs.w3.org will be treated as 
the official repository and can be used as such.

> 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).

I strongly believe that converging on a common dvcs (in particular 
mercurial since that is already in use) is a good thing.

Received on Monday, 9 May 2011 21:58:50 UTC