[CP2K:2904] How to use git as a client for the CVS server

[Toon Verstraelen]

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

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

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

cheers,

Toon