Re: Subversion vs Mercurial for test suite repository

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. What editor do you use? Perhaps it has Mercurial support (or there's one similar enough that does).

There's always the command line...

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

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

Received on Tuesday, 10 May 2011 23:06:24 UTC