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

["Hanssens Bart" <Bart.Hanssens@fedict.be>]

Hi Dennis,



I see your point about SVN-project actually being one product versus our
effort not entirely being able to fit under the same
trunk-tags-branches.


Perhaps I wasn't clear on this:
"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"

By this I mean that you shouldn't nest trunks. You can, of course, have
multiple trunks in the same subversion repository.
"Project" is also the term being used in the SVN book, but it's up to
the user to define the semantics: it can be a "component", "unit",
"subproject". It's perfectly OK to split up our "OASIS OIC TC project"
into a "SVN specanalysis project + SVN scenario project + ..."



If no-one objects, I create the Scenarios_TestDocs and push the test
case related trunk-branches-tags down.


So Dennis what do you think about changing the Specanalysis a little bit
into:

SpecAnalysis - trunk - 1.1
                     - 1.2
             - tags
             - branches

Or

SpecAnalysis - 1.1 - trunk
                   - tags
                   - branches
             - 1.2 - trunk
                    ....


Probably most of the work will be done on trunk and perhaps we don't
really need the branches, so at first sight this might seem a little
bloated.

But I'd still like to have the "tags" that makes it easy to, well, tag a
certain revision once we're comfortable with it.


Regarding dependencies and releasing units, that's a good point.
Below are my thoughts and suggestions, hopefully I'm not raising more
questions than answers :-)

In a software project, one usually releases projects as a whole, not on
a per-component basis (unless perhaps LEGO or IKEA :-))
So that's where we might find value in branches: 

   SpecAnalysis - 1.1 - branches - review_chapter17


The review_chapter17 branch is actually a (lazy) copy of the whole tree,
for starters, it'll only contain chapter 17. 

If - when working on "review_chapter_17" - we find a dependency on
chapter 2 and 3, we can still continue to review it in that branch, and
do some work on chapter 2 and 3 as well by adding the required parts.
When done, merge it into the trunk, tag it as a "reviewed_17" and have
SVN generate a change log.

I'm using chapter merely as an example, it could be anything, for
instance the chapter on tables might be too big to handle in one go.



It seems to me that we should determine the "master" (authentic /
primary source, ...): will the review mainly be done using SVN, and
perhaps published on the Wiki ? Or the other way around ? Or forego the
Wiki altogether, and go straight from SVN to a report-document ?



Best regards,

Bart

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: woensdag 25 februari 2009 3:31
To: Hanssens Bart; oic@lists.oasis-open.org
Subject: RE: [oic] RE: SVN-Related Practices and Customs

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.