W3C home > Mailing lists > Public > public-css-testsuite@w3.org > May 2011

Re: Subversion vs Mercurial for test suite repository

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Tue, 10 May 2011 20:19:45 -0700
Message-ID: <94a728e82c6ea229dfd7c7f9334afde5.squirrel@cp3.shieldhost.com>
To: "Linss, Peter" <peter.linss@hp.com>
Cc: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>

Le Mar 10 mai 2011 16:03, Linss, Peter a écrit :
> On May 10, 2011, at 3:33 PM, Gérard Talbot wrote:
>> I am looking at KPackageKit (main KDE software management system)
>> softwares under "Developer tools" category and there are a bunch of
>> softwares supposed to support VCS, others CVS (eg Cervisia
>> http://cervisia.kde.org/ ) . If only I would be sure if CVS is the
>> same
>> as VCS.
>> CVS: Concurrent Versioning System ? Concurrent Versions System ?
>> VCS: Versioning Control System ? Version Control System ?
>> (newcomer question): Overall, what is the relationship between CVS (or
>> VCS) and SVN?
> VCS = Version Control System
> - this is simply a generic term to describe all systems that provide
> version control.
> CVS is a particular VCS, as is SVN (Subversion), Hg (Mercurial), RCS,
> DARCS, Git and others.
> CVS is a newer version of RCS (it allowed concurrent editing of files),
> SVN is a newer system designed to replace CVS (it added version control
> of directories among other features).
> Mercurial, Git, DARCS and others are DVCS or Distributed Version Control
> Systems. They don't rely on a central server or repository, essentially
> everyone gets their own repository and they can push/pull changes among
> each other.
> If we switch to Mercurial, we'll still have our own server
> (hg.csswg.org) which will contain the authoritative copy of the
> repository, users will clone the repository onto their own machines, do
> their work there, and push changes back to the central server as
> necessary. This isn't as scary as it sounds (or doesn't have to be
> anyway), for the most part, user's workflows wont change much. Rather
> than do a "svn update", you'll do a "hg pull" then "hg update". Rather
> than a "svn commit" you'll do a "hg commit" then "hg push". There are
> several other interesting ways of using a DVCS, but I'm not going to get
> in to that here.
>>> and see if any of them meet your needs. There are also several
>>> editor environments that integrate with it.
>>> See:
>>> http://mercurial.selenic.com/wiki/OtherTools
>>> TortoiseHg has Gnome/Nautilus support, I don't know if that can work
>>> for
>>> you...
>> Gnome/Nautilus is for Ubuntu. I use Kubuntu. TortoiseHG is not in the
>> list of development softwares for KDE anyway.
>> Right now, when I list all possible Version Control softwares for KDE,
>> I
>> get a list of 10:
>> Bazaar Explorer
>> Bazaar Version Control System
>> Cervisia
>> Cola Git GUI
>> Giggle
>> gitg
>> gquilt patch manager
>> KDESVN (which I have used and use so far)
>> qgit
>> tkcvs
>> and none of them are listed at
>> http://mercurial.selenic.com/wiki/OtherTools
>> unless gquilt == gquilt patch manager
> It looks like gquilt == gquilt patch manager, but at first glance this
> looks like more of a patch management tool and is probably not the kind
> of workflow you're looking for.
> Bazaar is yet another VCS, so that won't help you.
> Cervisia is a front-end to CVS, as is tkcvs.
> The others appear to be mad for Git.
> Not looking too good for a Mercurial GUI that integrates with your file
> explorer.

I wish I could be using something just like KDESVN. It took me a few
days to understand how to use it.

> What editor do you use?

You mean an HTML editor? I use BlueFish 2.0.2 (
http://bluefish.openoffice.nl/index.html ) but it does not support
Mercurial versioning or any versioning.

I also use jEdit 4.3.2 (sometimes for HTML editing) and it has HgPlugin
0.2 but it's a beta.

jEdit HgPlugin

> Perhaps it has Mercurial support (or
> there's one similar enough that does).
> There's always the command line...

If you can write a tutorial on Mercurial with the command line, then I'd
be willing to follow it, use it, learn from it. I would prefer it to be
"step-by-step", so that even ordinary "Joe Schmuck" could use.

>>> One thing, if you're making changes to your existing tests that have
>>> already been moved into approved/css2.1/src, please svn copy the
>>> files
>>> back into your submitted folder and then submit the changes there.
>> One question here.
>> If
>> /source/approved/css2.1/src
>> has 8000 testcases, then I will have to have a (mirror) local copy
>> (downloaded onto my system) of those 8000 testcases with the same
>> directory structure, right? correct?
> Basically. All the tests are in subdirectories from there so you could
> checkout only the ones your tests are in.
> It's easier (at least for me) to simply have a copy of the entire
> repository to work with on your system. Note that with Mercurial, not
> only will you have to have a copy of the whole repository, you get a
> copy of every revision to every file as well (it's compressed so it's
> not as bad as it sounds, but it will be many MiB). If you're really
> resource constrained so this can't work for you, then that's another
> argument against Mercurial.

No, I am not user system resource constrained, at least on local
hard-disk available space... although most of the people in this mailing
list working for a browser manufacturer are using very powerful PC with
lots of system resources... Everything is relative..

> If you need to copy files back from approved, but don't want to (or
> can't) checkout that part of the repository,  you can also ask someone
> else (like me, or Elika) to copy the files back into your submitted
> directory... (there's a planned workflow for the management system
> that'll let you do that through a web interface in the future...)

I'm not sure I understand your previous parg. Maybe I'm too tired..

Right now, I am overburdened as everything seems to be happening at the
same time on the same day.

I first want to work on all my testcases, put them in their best code
and format, then submit them with KDESVN. I want to do all this before
monday may 16th.

regards, Gérard
Contributions to the CSS 2.1 test suite:

CSS 2.1 Test suite RC6, March 23rd 2011

CSS 2.1 test suite contributors:
Received on Wednesday, 11 May 2011 03:20:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:54 UTC