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

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

Hi Bart,

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.

After mulling it over, I think I can build a collateral SpecAnalysis/ tree
for the specification explosion and analysis without requiring branch
points, and there are ways to introduce branching later, if necessary,
without having to change the structure of SpecAnalysis itself.  I'm going to
start out that way and hope I don't drive off a cliff.

 - Dennis

PS: Good catch about svn:external.  I am very accustomed to VSS sharing at
the individual file level and use it heavily in my projects.  But it is easy
enough to substitute (sub-)directory sharing if I anticipate properly.

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

It seems that the key determinant is identification of where one wants to
have peer copies or snapshots for some reason.  

For example, if I had some path like

SpecAnal/ - 1.1/ - 17/ - 17.2/ - stuff/ - foo
                                       |
                                        - wip

and I want to "branch" (actually "clone" at the same revisions) the stuff
folder, I can't do it into a subfolder of stuff.  So I would have to make
the branch into a different child of 17.2/ assuming tht I wanted some sort
of proximity.  That's confusing, because there may be other siblings of 17.2
and the naming gets wacky.  The alternative is to use something like

SpecAnal/ - 1.1/ - 17/ - 17.2/ - trunk/ - stuff/ - foo
                              |                 |
                              |                  - wip       
                               - tags/ - 17.2v01 / - stuff/ - foo
                                                           |
                                                            - wip

The branch point seems to depend on finding the lowest level where material
varies independently.  If there are cross-references among files beneath
different trunk/ points, life becomes more challenging.  (SVN is ignorant of
embedded cross-references and their version dependencies, so there's no help
for that no matter where there are branch points.)

One really doesn't want trunks under trunks.

If I were developing a specification this way, I would expect that there
would be wd01-named committee working drafts, which roll up into cd01-named
committee drafts, which roll up into cs01-named committee specifications
which roll up into os OASIS Standards, etc.  But I think I would make those
using svn:external to bring over the subsections that constitute one of
those.  For that case, I suspect that the normal choice of branch point
would be at the chapter level, because of the amount of in-chapter
consistency that is usually required.

For SpecAnalysis, the specification already exists and it might be best to
avoid branch points within the specification explosion altogether.  Then
test cases and their evolution would not be part of the same tree, even
though there would be some sort of connection in many cases.   

Having walked around this and kicked on the tires, I think I will avoid
introduction of branching points at all.  If we need them later, I think
there are alternatives that do not involve splicing branch-folder levels
into the existing structure.  

I am crossing my fingers ... 

  
                                      

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

Hi Dennis,

http://lists.oasis-open.org/archives/oic/200902/msg00065.html
> You created the current oic SVN top-level of trunk/, tags/, and branches/.
> I was wondering if that was just an automatic replication of a common SVN
practice
> or whether you have a strong requirement for using that structure across
the SVN.

the trunk-tags-branches approach is common practice and endorsed by the SVN
team
itself.
But I don't have strong feelings about it, so if you or someone else would
like to
create a different layout, then that's perfectly fine with me.

Especially since we're just getting started using SVN as an OIC tool, we'll
probably
need to experiment a little bit with it.


> There may need to be some consideration to how svn:external might be
relied upon to
> "share" content between versions.  That prospect might be valuable to
preserve (e.g.,
> for 1.1 tests that are also 1.2 tests, although the reorganization of 1.2
into three
> parts will also be challenging to match up against).

Not sure if we'll get much benefit of svn:external, IIRC, svn:external can
only be
used to grab directories, not for files (unlike sharing in, say, Visual
SourceSafe)
Perhaps setting a "odf-version" property is the way to go, to be discussed
:-)


Best regards,

Bart