Subversion usages

Question

Hi all,

I am just starting to use "Subversion" with "Tortoise SVN client" for one of my opensource project which is hosted on "Google Code". I would like to get some best practices on using it. I am following the default folder structure(trunk,branch,tag). Following are the questions

1. When will you do the initial checkin? Is it only after finished a set of features or from the first day of development?
2. To which directory the initial checkin goes? Is it into "trunk" or you checkin to "branch" and merge to "trunk" once a feature is complete. In this case "trunk" will be empty until the feature is done.
3. When ever changes are made, will you checkin to "trunk" directly? If not your working copy will be always using "branch" directory, right?

Any help would be appreciated.

Answer 1

1. I recommend you to check in your files before you start to do heavy modifications to them (check in early, check in often).

2. It depends, some people like to have the trunk stable, work in branches and then merge the branches back to the trunk when the features are ready, but you can also commit directly to the trunk.

3. It also depends on how you will work and what do you like to have in trunk (the latest stable version or the latest bleeding edge version).

Answer 2

I suggest checking in early and often.

There are many ways to do this, but the most common I have successfully worked with is working off a development branch and merging to the trunk when you get to a stable point (minor version releases, milestones, etc).

If you haven't already, check out the red book, it is a great resource for svn information.

Answer 3

When creating a new project from scratch I usually do so in a user area in SVN such as

/svn/users/me/project1

this is because most projects start out as throw away prototypes and I rarely use branches for these. Once a project becomes official and nears it's first "prototype" release I will migrate it over to it's own repository

/svn/project1/trunk

The use of branches require a bit of extra work so we don't use them unless they're necessary. Which is when multiple people are working on the same project and collisions are often or I'm working on a feature which I might decide to revert and throw away. If done in a branch I can simply choose not to merge and just delete it.

Answer 4

All answers suggest that you check in early, check in often, I couldn't agree more. So thats all I'll say about that. However, I read the summary as: What kind of uses can Subversion fit? So here's an answer for that.

I've read about companies using Subversion as their application repository. So, they tell the server that they want to install Version X of application Y. Then the server runs an update on the SVN server. And they also stored configuration files in there too. And any changes made to the config (via a separate web interface for end-customers) were then committed to the SVN config repo. This is brilliant. 'Course these guys were using MS Power Shell on Win2k3, but still the technique can be applied elsewhere.

Answer 5

Check in IMMEDIATELY, not early. Even if you have nothing more to commit than an ad-hoc text file containing brainstorms and some horribly cryptic psuedo code, commit it.

I (like many) find projects just like your's while doing some kind of code search, or searching for a program that does what I want. I will read your front page then immediately browse your SVN trunk to see what you're doing.

If you have zero code in the trunk, I'll likely forget all about you. If you have at least some file explaining your intended design and some psuedo code, I'll likely start sending you patches that show my ideas.

A project with an empty repository screams "itch that will never be scratched" .. so push something as soon as you can.

After that, commit often. I like to make many small, ordered commitments so its easy to track regressions and roll back/fix toxic revisions.

Answer 6

1. Check in once you have created your blank baseline project/solution structure. Blank because at this state it is actually compilable albeit no working code. The principle is to keep the entire project - at least - in a compilable state throughout development as the team incrementally and regularly commits small changes, so that the build hardly gets broken.

2. There is no law requiring the initial check-in must happen at the Trunk or a Branch. You may start up the Trunk with empty project so it is stable right from the start, then branch out to carry out development and merge it back to the Trunk once complete. You may also choose to check-in the empty project to a Branch and develop the first working or base feature before merging something substantial into the Trunk. Either way, based on point #1 the Trunk should be stable and high quality. Only merge high-quality content into the Trunk.

3. Again there is no strict mandate on this type of practices. Some teams branch out everything, even simple refactoring of variable name changes. Some teams do not even know branching/merge and develop everything in a single branch (the Trunk). Every team has its own level of balance on this issue. My personal guideline is if there are going to be new features or major bug fixes or re-design, branch it out to test. If it is a minor fix like string spelling errors or displaying four decimal places instead of two in the web page, fixing the Trunk copy should suffice. Of course, interpretations of "major" versus "minor" are going differ so the development/team leads should establish their standards. Either way, there must be unit/integration tests accompanying the changes to verify the Branch or the Trunk are working as intended, as defect-free as possible. The keyword to remember is always "high quality, tested code".