views:

79

answers:

2

Hello, I'm trying to get into Python and, more specifically, Zope and Plone. I read the book Professional Plone Development and one thing it says is that one MUST use version control. But the book did not expand on that topic any further. This leads to two questions.

First: SVN or git? (My research points to git, if only to learn it. I've only used SVN so far.)

And second: Which files should be handled by version control? Settings and my own code? The whole Zope directory? Not the data.fs, surely? Not the .pyc files, I'm sure of that. I've taken a break from Plone for that reason these days, and I couldn't find a good guide for that. In short, so far, when I synchronised the data between my local PC and my web server, things broke. Badly. And I'm not sure why. Either some updates were missing, or some platform-specific files were updated. My home PC is 64 bit Ubuntu and my distant web server is 32 bit RHEL. It felt like such a mess, and like such a dangerous mess, that I'm a bit apprehensive of going back near it.

Is there a way to know which files should be handled by a version control system and which should not?

Thanks.

A: 

To the first question: whatever system suits your fancy. Subversion and Git are both decent options. A potential plus for Git (or another DVCS like Mercurial or Bazaar) are that they're a lot more straightforward to set up in a local directory - generally just a single command.

To the second: basically, put anything that's not a transient file under source control. So yes, exclude pyc/pyo files, and also any test database files et cetera, but anything that's code should probably be versioned. Config files are a toss-up - some people put them in version control, others don't.

Amber
So, phrased differently, your advice would be to include the original Zope/Plone code in the version control system, minus what you said (such as compiled files, test database files, and possibly config files). Include the Plone/Zope code.
eje211
Yes. Firstly, you may eventually make modifications to that code if you need to add something in (or modify it to suit your purposes). Secondly, if you ever decide to upgrade versions or some such, having the original code in version control means that you'll be able to easily roll back to the old version if necessary.
Amber
+1  A: 

I put only my buildout files into svn (dir: project/buildout/trunk). Buildout fetches all Plone/Zope files in the right versions.

Additionally i put my eggs in svn (dir: project/eggs/trunk). My eggs hold all the modifications into Plone.

My buildout uses mr.developer to auto fetches my eggs.

You ca check http://toutpt.wordpress.com/2010/07/07/nantes-developpement-com-a-new-plone-website-by-makina-corpus/ its a big buildout and uses all kind of mods and extensions.

+1. It is a good idea to set up your ignore file (.svnignore,.hgignore, or .cvsignore, or whatever your vcs ignore file is called) first thing to be sure that nothing gets in that you don't want.
Warren P
After a lot of reflection, I'm picking your answer as correct. It is more specific to Plone, and trying to include everything DID result in a mess last time. (But then, if I do something different now, I don't want to do it at random, thus the question). Also, buildout SHOULD take care of the Plone and Zope files on its own, and changing the files behind buildout's back seems to be a bad idea. You appear to confirm that feeling.
eje211