Svn practices

This page is still under review.

1) Read-only access. This is meant for people that don't know that well what version control is but want to grab the code and play with it.

It should contain how to do a checkout, update your tree, what the branches are and how to apply, revert or generate patches, It's actually a good practice to use svn diff to generate patches as it contains the information of the specific revision used to generate it.

2) Write access. There is a guide for new committers: http://www.apache.org/dev/new-committers-guide.html

But I actually think that a quick guide that explains how to set the default properties and how to do the simple tasks would be great. My tips here are

I highly recommend:

1) specifying in the command line a list of the files/dirs that are changed to avoid accidentally committing unwanted changes.

2) Use of a template for the log file with the author and other information. This is wrong: svn commit -m "My changes" This is right: svn commit ci -F ../mychangelog.txt change1 change2

3) Remind people to add the revision information in Bugzilla for crossreference, if it applies.

This chapter should also explain how to create branches for bigger tasks and how to merge changes to a branch.

For reference, FreeBSD has a SVN Primer, and the Merging section has some complete instructions: http://wiki.freebsd.org/SubversionPrimer/Merging

Of course FreeBSD is more complex in structure and has many more committers so some additional rules are in place:

In general we don't commit things directly to the branches unless we have to and in that case the Release Engineer has to approve the change. There's no such thing as lazy consensus there ;). We also set as minimum three days (I usually take a couple of weeks) before merging any change to the stable branch.