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
svn
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:
- Each project has its own repository
- Each repository has a set of directories: tags, branches, trunk
- Tags are immutable copies of the the tree (release, beta, rc, etc.)
- Branches are typically feature branches
- 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