RE: [oic] RE: SVN-Related Practices and Customs

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Thanks, Bart,

I looked at the Subversion project at <http://svn.collab.net/viewvc/svn/>.
The do indeed have trunk/, tags/ (for releases), and branches/ at the top
level, along with some other material that has been factored off of the
trunk.

It seems that there is only one product and its progression of releases,
including all of the tools, build and test procedures, etc., that were
applied in that release.  So the progression of releases is for the whole
trunk.

I remain doubtful that is so applicable to what we are doing, but we will
see once there is more to have to keep organized.

Meanwhile, the SpecAnalysis hierarchy is at the top of the oic SVN adjacent
to the trunk.  We'll see what happens when we see what may be releasable
units.  If this were a development project, I think managing dependencies
would be a factor as well, but I'm not quite sure how that will apply for
us.

 - Dennis 

PS: I recommend the book, and I find TortoiseSVN and its documentation to be
extremely useful as well.  

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
http://lists.oasis-open.org/archives/oic/200902/msg00082.html
Sent: Tuesday, February 24, 2009 02:06
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Subject: RE: [oic] RE: SVN-Related Practices and Customs

Dennis,

http://lists.oasis-open.org/archives/oic/200902/msg00072.html
> I noticed the preference for a top-level branching (from trunk/ to
> branches/ and /tags) in the SVN documentation, although the examples
> explored most fully involve multiple projects, even grouped projects,
> with the individual projects having their own trunk, branches, and tags
> sub-folders.

Yes, that's another approach. Apache does this with their projects.
On the other hand, the SVN project maintains their code, tools and website
in a single trunk-branches-tags hierarchy.



> I looked around a little more in the free O'Reilly Version Control with
> Subversion: for Subversion 1.5.

For those who aren't familiar with it: http://svnbook.red-bean.com

And on Windows you have this wonderful tool http://tortoisesvn.tigris.org
Of course there are lots of other tools as well on other platforms.

[ ... ]

IMHO it would
be better to do it like this for non-trivial amounts of work

SpecAnal/ - trunk/ - 1.1/ - 17/ - stuff/ - foo
                                        |
                                         - bar
            branches/ - working_on_17/ - 1.1/ - 17/ - stuff/  - foo
                                                             |
                                                              - bar

In SVN this is a lazy operation, so creating a branch hardly takes up any
space (probably you can also "copy" a single subdirectory to the branch, but
IIRC that makes merging slightly more difficult. Haven't used it for a while
so if anyone can clarify this... :-)

Once you're happy with the branch, you could then merge it back to the
trunk.

This way the trunk stays "stable". For trivial changes, one might directly
change it in the trunk, otherwise we'll end up with branches for every typo
or small improvement.


And after a while, when having a decent number of changes, we could create
a tag called "review_01" or whatever.


> One really doesn't want trunks under trunks.

No, actually the whole point is to only have one trunk/tags/branches
structure,
be it at the root or as a (first or one of the first) sublevel of your
project


So perhaps it would be wise to organise it like this:

Scenarios_TestDocs / - trunk/
                     - branches/
                     - tags/

SpecAnalysis_ODF11/ - trunk/ - 1/ - 1.1/ ....
                    - branches/
                    - tags/

SpecAnalysis_ODF12/ - trunk/
                    - branches/
                    - tags/

FooBarStuff/...


I'm assuming here that many test scenarios / documents can be reused by
simply setting a custom property "odf:version" on the file, while it will
be more confusing to do the same thing for spec analysis due to change in
chapter numbering and so on. Feel free to comment on this.


Even if we currently don't do branches. It used to be the case that, when
doing a move / rename, you'd had to flip an option in your tool to see the
whole history log. No big deal actually, but if we can avoid it...


Best regards,

Bart