[Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
wrobel at pardus.de
wrobel at pardus.de
Thu Feb 25 22:42:46 CET 2010
Hi Richard,
as I am also in favor of git but do nevertheless support the choice of
mercurial for Kolab I would like to try to convince you ;)
Quoting Richard Bos <ml at radoeka.nl>:
>
> Op donderdag 25 februari 2010 18:25:02 schreef Gunnar Wrobel:
>
> -1 (I do not agree, please add a short rationale)
>
>> If I had to make the decision I would still go for git as I have the
>> impression that this is currently developing into the mainstream
>> successor following cvs / svn. The whole PHP world seems to have move
>> into github during the last two month :)
>
> Not only PHP, but many other projects are moving to git. I hardly hear
> anything from Mercurial. It might that at this moment it is easier to move
> from cvs/svn to mercurial compared to git, but in the coming years
> when git is
> the code repository on the internet, Mercurial will be a stranger.
While I agree that git is probably acquiring new users at a faster
pace Mercurial is certainly no "stranger". It is supported by Google
code as well as SourceForge (http://mercurial.selenic.com/wiki/) and
projects like Mozilla and OpenOffice are running on Mercurial
(http://mercurial.selenic.com/wiki/ProjectsUsingMercurial).
> This may make it harder to attrack developers in the future.
I disagree. I do believe that the choice of the revision control
system has nearly no influence on the decision to join a project or not.
We accepted that the Kolab Server used CVS for the past years. Did we
consider the project to be bad or broken because of that? Did it keep
people away? I don't think so. Of course it was annoying once Gunnar
moved just another directory to a new location. But as far as I know
nobody dropped out because of that. At least I hope so :)
> I've no experience with either git or mercurial, so can't really determine
> which one is nicer.
As far as I can tell Mercurial is. Git is very techy and appears more
powerful to me. And there are features that I love (patch queue
management) that you don't get with Mercurial. But Git is complicated
and if you come from cvs/svn then Mercurial is definitely easier.
> The one thing I know is that files via urls offered by
> Git look stange to me. On the other hand I would like to learn git, as this
> experience may be needed for other projects like KDE. I don't believe I'll
> use mercurial for another project.... As I already mentioned KDE, the KDE
> developers will be using Git in the future and openSUSE already does. If
> Kolab would move to Mercurial you force those people to learn yet another
> (perhaps similar, but still another) code version system.
As OpenSUSE already uses git I'm assume you will learn git soon anyway.
And as there is not that much new in mercurial when you come from
cvs/svn all that will happen is that you know four revision control
systems rather than three. And to be honest: As cvs/svn/hg are pretty
similar it will be more like knowing two: cvs/svn/hg and the "strange"
git kid.
>
>> - Intevation has expert knowledge and operating experience in
>> Mercurial while only user experience in git.
>
> Good point. But Git will be more used in the future than Mercurial, so it
> might be good oppertunity to get more Git operating experience.
Thomas did not clarify what "expert knowledge" means in that case.
Look at http://mercurial.selenic.com/wiki/DeveloperRepos under
"Special Repositories" as well as
http://mercurial.selenic.com/wiki/ThomasArendsenHein.
I doubt Thomas will suddenly start coding on git :) so that kind of
experience in git will be hard to reach. We would simply have users
experience, not more.
And if you find anything within git which you cannot find in
mercurial, go nag Thomas. He'll probably tell you how to do it in a
nicer way in hg.
Though... I still don't know how to get something like topgit
(http://repo.or.cz/w/topgit.git) in hg. Thomas? ;)
>
>> - 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.
>
> Scratch this itch, isn't that the mantra of open source software. Lots of
> other OSS project will benefit of short / simple url's.
As mentioned above I don't see us coding on git. We barely have enough
time for the Kolab 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
>
> In the future mercurial is stranger and not the mainstream. It would mean
> more difficult to learn...
I already disagreed above.
And from my experience as a developer I would say that the revision
control system does not really count that much. In most cases you
can't decide that anyhow and you are forced to know many of them.
If you ask me then both CVS and SVN can simply go away and cease to
exist now that I know what the advantages of distributed revision
control systems are.
However I will need to use both of them throughout the years to come.
There will always be the one or the other project still using them.
My 2cents. I hope I was able to move you from -1 to 0 ? Maybe? ;)
Cheers,
Gunnar
>
>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
--------------------------------------------------------------------
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100225/136517db/attachment.sig>
More information about the devel
mailing list