Re: [SQLObject] Releases and versioning.

[Alan K. <sql...@xh...>]

[Alan Kennedy]
 >> But I see that the tagging is not used in that repository.

[Ian Bicking]
 > No.  There's no deep intention behind it.  OTOH, tagging vs. branching
 > seems like a CVS concept, though maybe still a useful metaphor.  A tag
 > is just a branch that we agree not to update.

and

 > Sure, I'm open to suggestions on the subversion layout.  At some point
 > I'll probably refactor it some, at the same time that I move to http
 > (Apache, instead of the standalone server).

Thanks for the reply Ian.

I think the fact that we're even having a discussion about the merits of 
"branches" vs. "tags" and whether they're useful or not is indicative of 
a problem of confusing legacy terminology.

But, subversion makes it easier to use whatever terminology is 
appropriate to the scenario, so I think it best to avoid this kind of 
semantic confusion and name things for what they explicitly are.

Therefore, I would propose to use a "releases" url to hold releases. 
Then use "branches" for the "traditional" meaning of the term, which is 
to be parallel active development trees, e.g. the "inheritance" branch.

Then getting release 0.5.2 or 0.6.1,  would become

svn co svn://colorstudy.com/releases/SQLObject/RELEASE_0_5_2
svn co svn://colorstudy.com/releases/SQLObject/RELEASE_0_6_1

Checking out a copy of the inheritance branch would become

svn co svn://colorstudy.com/branches/SQLObject/inheritance

Also, it should be possible to restrict permission on the "releases" 
subtree, meaning you could restrict permission to make releases, but 
still allow development activity on other sub-urls.

Just one suggestion.

Cheers,

Alan.