[CP2K:2904] How to use git as a client for the CVS server
Toon.Ver... at UGent.be
Wed Nov 3 22:46:39 CET 2010
On 11/03/2010 11:01 AM, hut... at pci.uzh.ch wrote:
> just some remarks on the topic from my side. When we set up the cp2k
> server at Berlios, CVS was the only option as a source control
> system. Since then discussions on moving away from Berlios and CVS
> are coming up regularly. On Berlios they currently also support
> 'subversion'. Up to now, the pain of changing the host and/or the
> source control system has been considered too big compared to the
If ever necessary, I can always help. The actual conversion is easy.
Getting used to a different system is hard, but may pay off in the long
run. Berlios apparently added support git and mercurial recently.
> The core developers of cp2k also prefer (at least the last time I
> inquired) a centralized system (meaning e.g. subversion over bazaar).
> The reason is that we believe that this way development is more
> transparent and there will be less conflicts. I know this topic is
> very controversial, just do a Google search on the topic and you will
> find ample discussions. However, if somebody feels more comfortable
> with another more local, decentralized system we (ok, I can
> only talk for myself) don't want to hold you back.
Thanks for clarifying. There is no hurry. I agree there is a lot of
discussion about this on the web, but I'll try to explain why I'm pro
decentralized. If it is not convincing, so be it.
When coding, I don't suffer much from the CVS, because conversion to git
is doable. Only occasionally I send a polished series of patches (or a
branch if you like) to Teo, who does a great job in reviewing and
committing. It is a defacto decentralized work flow. There is no
confusion because nobody cares about my development branches. Most of
them remain private anyway, except when I go testing on other machines.
As a user, I do dislike the centralized approach and the volatility of
the CVS master branch. It is even worse when I'd like others to use
CP2K. It takes luck to check out a CP2K revision that is reliable for
production work. I do not want to give complaints without working on a
The volatility issue is the main motivation behind the decentralized
approach: one organizes and tests series of patches locally. After some
time (e.g. a week) all patches including bug fixes go in the master in
one shot, which reduces the chance on a malicious checkout. It is just a
natural way of getting closer to stable releases. It requires some more
discipline of all contributors, but one does not need a super-hero to
derive a stable branch.
I've read old posts on this list discussing the same issue. The
ENABLE_UNSUPPORTED_FEATURES keyword was once introduced to distinguish
between reliable and unreliable parts of the program. The main weakness
is that it does force people to write code in an organized fashion, e.g.
testing, documenting, reviewing, etc. before committing to the master.
Next to the decentralized approach, an absolute validation suite is also
mandatory to make a reliable program. It is a separate thing that I'd
like to discuss too. (See next post.)
More information about the CP2K-user