[Kolab-devel] Poll: Kolab server switching to Mercurial SCM?

[Corey Schuhen]

Hi all,

I have been subscribed to this list for many years so I thought I'd offer my 
AU$0.02. Of course, as I am not actually a Kolab developer(just a happy user 
for lots of years) there is no point including me on the poll.

Where I work, we develop embedded vehicle control systems. We develop under 
Linux with an RTEMS PPC target. For RCS, first we were using CVS, then switched 
TLA(it was horrible, though I have heard bazar is better now) before finally 
moving  to mercurial (2 years and 10 months ago) with 9k change sets. Our 
source totals 30M and the .hg directory in a repository is 70M. b.t.w. We have 
5 developers on our team plus some on other teams that use our code. I'm just 
providing this information to given an idea about the size of our project.

Anyhow, to the point of my email, I just wanted to say that since the switch, 
we all have nothing but praise for mercurial. We are especially happy that it 
scales so well, all operations happen at a a good speed. The distributed 
nature means that you spend very little time waiting on network bandwidth, 
only when doing push/pull. Merges seem to work pretty well, sometimes needing 
some help if multiple users change the same lines but we expect this :)


Regards,

Corey



On Fri, 26 Feb 2010 01:29 amLOG you wrote:
> Hi!
> 
> I think everyone agrees that we want to get away from CVS, primary
> reasons for this is to be able to move files around without breaking
> their history and to get a single revision number to identify
> builds, which is important e.g. for automated builds.
> 
> Although we will continue to use a central public repository, some
> of the developers (including Sascha and me) want the ability to do
> refactoring or bigger changes without interrupting the work of
> others or just do some local modifications for testing or for
> customers and still be able to commit often to save their progress
> and to split their work in smaller parts which can be reviewed more
> easily. Therefore (and for some other reasons) the next SCM will not
> be Subversion, but a distributed SCM.
> 
> Main contenders for this are Mercurial (hg) and git, but for the
> following reasons we see Mercurial as the better choice for the
> development of Kolab Server:
> 
> - Intevation has expert knowledge and operating experience in
>   Mercurial while only user experience in git.
> - The web interface offers simple and short URLs for downloading
>   single files or patches, this is already used with the viewcvs
>   interface for user documentation and for patches which have to be
>   applied to e.g. Cyrus imapd to add features required by the
>   server.
> - Usage of Mercurial is easier to learn for people already knowing
>   CVS or Subversion, because the UI is quite similar, see e.g.
>   http://mercurial.selenic.com/quickstart/ or
>   http://mercurial.selenic.com/wiki/CvsCommands
> 
> So I would like to ask for short feedback (as I do not want to spend
> too much time on discussion if everyone already is happy enough with
> this) about what you think about switching to Mercurial.
> 
> Please choose one of:
> +1 (I want it)
>  0 (I can live with it)
> -1 (I do not agree, please add a short rationale)
> 
> Deadline for this poll is next Thursday, March 4th, 12:00 UTC.
> 
> If we get a negative result, we will start a more in-depth
> discussion.
> 
> Regards,
> Thomas Arendsen Hein
> 
> -- 
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 
0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 
18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>