Strategy

My strategy, such as it is, is to work in the trunk and create tags for final versions. This means the trunk may have broken code. My buildout.cfg file will be responsible for specifying the correct tag to check out to recreate an operational site. Generally my work isn't split out enough to require a strategy that uses branches and merging them back into the trunk.

Re-running the buildout will always result in a working site, though most recent, uncommitted product changes in the trunk will not be included. And that's fine.

Global ignores need to be set for .pyc and .bak files. These have to be set on each machine I use (Mac, PC). The .DS_Store files are only present on Mac OS. In the ./subversion/config file, set:

global-ignores= *.bak, *.pyc *.DS_Store

Windows doesn't use a config file by default, or make it easy to find. There's a technique that requires editing the registry, but for simplicities sake, I followed Ned Batchelder's tutorial. A better tutorial for setting up Subversion on Windows.

Put the product into the repository

  svn import pdmSite https://svn.combsnet.com/pdmSite/trunk \

  -m "initial DIY template"

  svn mkdir https://svn.combsnet.com/pdmSite/tags

Create a tag for the 1st version

  svn copy https://svn.combsnet.com/pdmSite/trunk \

  https://svn.combsnet.com/pdmSite/tags/release-0.1 \

  -m "Release 0.1 is the default template"

Check out the code into your /products directory

Go to the products directory and use:

svn checkout https://svn.combsnet.com/pdmSite/tags/release-0.1 pdmSite

If you've worked on this from another PC, and want to make sure that your local working copy has the latest, use svn update (no args).

To checkout your buildout.cfg file, go to the dest directory and use:

svn checkout http://svn.combsnet.com/plone25buildout/trunk .

Work, work, work

If you add or delete files or directories, use svn add foo, svn delete foo, svn copy foo bar, svn move foo bar, or svn mkdir foobars.

Review changes

  Use svn status to see a list. "C" means the item is in conflict. I shouldn't see that, as a single user of the system. A = add, D = delete, M = modified.

  svn diff (no args compares to checked out version) -r <revision> foo

  svn revert foo

  svn cat -r <revision#> foo

  svn list <url>

Check the code back into the repository

Check the draft code in frequently as a backup measure, and to make it easier to revert to prior drafts.

For a product, move to the site root and use:

svn commit -m "changed the skin color"

When you reach a "release", create a new tag, and update the buildout.cfg file to point to the new tag.

For checking in the buildout, go to the directory with buildout.cfg and use:

svn commit buildout.cfg -m "added a product"

As above, tag good releases.

Go to Webfaction and checkout the new good release of buildout.cfg, and then rebuild using it.

One change has to be made between the local buidout.cfg and the Webfaction version. The Webfaction will have this line:

http-address = 3036

Which should be commented out at home. Try to remember to uncomment it before you check it back in.