[En-Nut-Discussion] Moving to Subversion

[Marti Raudsepp]

On Sun, Mar 1, 2009 at 9:24 PM, Thiago A. Corrêa
<thiago.correa at gmail.com> wrote:
> Just my opinion on this, please don't take anything personaly.
Unlike you, everything I say is pure fact. ;)

> Different projects have different requirements, just because others
> are using something else, it doesn't mean we should.
Certainly, but my point pretty much is that distributed version
control systems can do anything that SVN can, and more. Why settle for
the inferior?

> Also, we host our code, bugtracker, etc at SourceForge. Anything
> different than CVS or SVN would be considering moving the hosting of
> the code at least.
For those of us who hate SourceForce, that would be a bonus.

> There is also another concern: The revision history. SVN has ways of
> converting the CVS repository without loosing the history.
As do other version control systems.

> On the other hand, normal operation is different from what we are used
> to. I for one was never able to understand git, and I'm not going to
> try either.
I can second that, git used to have awful documentation and a terrible
command line interface; this has changed a lot recently.

Mercurial always tried to be the user-friendlier one. I can recommend
Bryan O’Sullivan's "Distributed revision control with Mercurial" book
for an introduction: http://hgbook.red-bean.com/hgbook.html

>> * Revisions can be commited by anyone and later merged into the main
>> repository by trusted users: The version control system is useful for
>> those without commit access.
> I use buildroot with my own copy of the repository (vendor branches)
True, you can do that, though it sounds a bit tedious.

> I've used Subversion for ages, and performance of subversion itself
> have never seem to bother me. We spend far more time wainting for gcc
> to do it's job every day than subversion or CVS for that matter.
I used to think that SVN was fast too. Now every time I need to use
SVN, I find myself tapping my fingers on the table. Sure, compilation
also takes time, but we aren't switching the compiler here.

Here's a few more points that popped into my mind why I prefer hg:
* With SVN, if you try to commit to a repository that has newer
changes, you have to merge local changes with HEAD before you can
actually commit. This always seemed backwards to me, and tends to
confuse people who are new to SVN.
* A built-in web server that you can launch typing just 'hg serve'.
This can be accessed with a browser as well as cloned/pulled from. I
never liked ViewVC.
* Mercurial queues (a'la quilt) provides a nice way to experiment with
larger (multi-revision) changes locally. It takes time to learn how to
use it though.
* Having commit and push as distinct steps means that there's a window
of opportunity to correct last minute mistakes. 'hg rollback' is handy
for undoing the latest commit.
* Metadata is kept in .hg under the top-level directory -- instead of
a .svn in each subdirectory of the project.

Marti