SVN naming convention: repository, branches, tags

Posted by LookitsPuck on Stack Overflow See other posts from Stack Overflow or by LookitsPuck
Published on 2010-05-26T17:42:12Z Indexed on 2010/05/26 18:31 UTC
Read the original article Hit count: 582

Filed under:

Hey all!

Just curious what your naming conventions are for the following:

Repository name Branches Tags

Right now, we're employing the following standards with SVN, but would like to improve on it:

  1. Each project has its own repository
  2. Each repository has a set of directories: tags, branches, trunk
  3. Tags are immutable copies of the the tree (release, beta, rc, etc.)
  4. Branches are typically feature branches
  5. Trunk is ongoing development (quick additions, bug fixes, etc.)

Now, with that said, I'm curious how everyone is not only handling the naming of their repositories, but also their tags and branches. For example, do you employ a camel case structure for the project name?

So, if your project is something like Backyard Baseball for Youngins, how do you handle that?

backyardBaseballForYoungins backyard_baseball_for_youngins BackyardBaseballForYoungins backyardbaseballforyoungins

That seems rather trivial, but it's a question.

If you're going with the feature branch paradigm, how do you name your feature branches? After the feature itself in plain English? Some sort of versioning scheme? I.e. say you want to add functionality to the Backyard Baseball app that allows users to add their own statistics. What would you call your branch?

{repoName}/branches/user-add-statistics {repoName}/branches/userAddStatistics {repoName}/branches/user_add_statistics etc.

Or:

{repoName}/branches/1.1.0.1

If you go the version route, how do you correlate the version numbers? It seems that feature branches wouldn't benefit much from a versioning schema, being that 1 developer could be working on the "user add statistics" functionality, and another developer could be working on the "admin add statistics" functionality. How are these do branch versions named? Are they better off being:

{repoName}/branches/1.1.0.1 - user add statistics {repoName}/branches/1.1.0.2 - admin add statistics

And once they're merged into the trunk, the trunk might increment appropriately?

Tags seem like they'd benefit the most from version numbers.

With that being said, how are you correlating the versions for your project (whether it be trunk, branch, tag, etc.) with SVN? I.e. how do you, as the developer, know that 1.1.1 has admin add statistics, and user add statistics functionality? How are these descriptive and linked? It'd make sense for tags to have release notes in each tag since they're immutable.

But, yeah, what are your SVN policies going forward?

© Stack Overflow or respective owner

Related posts about svn