RE: [oic] RE: interop advisory, example - SVN Limitation

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

I see two situations here.  

  1. Tagging versions (which means creating a tree fork that holds the
specific versions) and

  2. creating immutable copies and managing their revision without changing
them.

1. ABOUT TAGS

We should use tags (that is what I meant by labels in the earlier note).

The way I understand it, you are proposing to tag below the individual
advisory number.  (It looks like you don't need a trunk label in that case,
just for the tagged ones on a different path, but there is a great variety
of approaches to choose from here.  I agree we need tags for snapshots that
are to be held as stable [virtual] copies in some identified state, as
opposed to continuing check-ins on the main development folder for the
advisory.)

I had been thinking of tagging the versions of multiple advisories included
in a particular compilation that represents approved work for us.  

There might be both kinds of tagging, actually.  One for the various draft
and their tagged state snapshots, one for snapshots of those advisory
versions included in a particular composite compilation.  It keeps the trail
of development, approval status, and compilation visible.

2. ABOUT KEEPING IMMUTABLE COPIES ON A TAG BRANCH

Regardless of the various levels at which we implement tag sets in the SVN
tree, it seems the case that SVN will allow check-ins against any branch or
tag and reserving tags against changes is accomplished by agreement among
those who have check-in privileges.  

I assume that check-ins against a tagged set of documents can be reverted if
detected, although it would be nicer and simpler to have a true lock.  The
way this happens with OASIS documents is by having the CDs, CSs, and OS
versions on a server space that is not alterable by TC Members or the
public.

That might be the way to do it here too.  Draw a working copy of a newly
created tag into a different server space that is read-only to all once
created.  This also provides a reference copy for recovery of the tag if the
SVN is every corrupted.  The other thing I like about this is that the
working copy has the $Id$ entries filled in.  This would be the material
cross-referenced from any compilation document, having published URLs, etc.

Another way to do it would be to have a separate SVN Repository instance
that a tag set is moved into and then made only readable with no check-in
privileges on any accounts but the administrator.  I like the secured
working copy better.  It's less fuss although it is not so easy to make your
own off-OASIS copy as it is with taking updates from SVN.  But there could
still be the tag on SVN for the set, it is just that there is an immutable
snapshot which becomes the public reference.  I think this would only be
required to preserve the compilation-included sets, so it is an infrequent
action.

3. HANDLING LATER VERSIONS OF IMMUTABLE DOCUMENTS

That leaves one problem.  If a preserved entry is obsoleted or has a later
version, there is no way to know that, because the reference copy is
immutable.  The IETF has the same problem - RFC and even working drafts are
never altered, though working drafts can disappear after a period of time.
RFCs are immutable and never disappear.  They handle the obsolescence and
updating in the index to the RFCs, not by touching the RFC files themselves.
So if we wanted an advisory document to link to a latest version, it should
link into some sort of index which provides the threads.  (The only problem
here is linking into the future.  Keeping links to previous versions is no
problem, of course.)  This seems workable.  The index is subject to possible
corruption or damage, but that is easier to handle as a focused problem, it
seems to me.

There is more to look at here to ensure that end-to-end use cases work out.


We can certainly begin to organize SVN on the assumption that there might be
working-copy snapshots for capturing immutable sets whether or not that is
accomplished.  I suspect that we can have good practices for the SVN work
that supports such a possibility whether it happens or not.

4. NEXT STEPS?

We should reflect a bit on how we name and organize in anticipation of
needing to tag in different ways and also to make snapshots (including .zip
archives) for retention of reference versions.  In particular, the tree
should be relatively comprehensible for a member of the public to navigate
or to set up their own copy, with or without using SVN to do it.

I think it is important to visualize the end game enough that we don't drive
into a cul-de-sac.  I would start by paying attention to how others not on
the OIC TC could access and navigate the materials and know what it is they
are dealing with.

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Monday, June 14, 2010 06:48
To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
Cc: 'Cherie Ekholm'
Subject: RE: [oic] RE: interop advisory, example - SVN Limitation

Hi Dennis,


> One limitation of SVN, just as of the Wiki, is the lack of a way to lock
> down any branch so it can't be altered, even by someone with commit
> permission.

One can create tags, that might do the trick in our case

So instead of 

/trunk/Advisories/0001

We could do this:

/Advisories/00001/trunk/adv.html
/Advisories/00001/trunk/adv.odt
...
/Advisories/00001/tags/1.0
/Advisories/00001/tags/2.0
/Advisories/00001/tags/latest
...

Workflow would be: 

- work on draft versions in trunk
- tag the approved one 1.0
- tag again, using "latest"
- continue the work on draft versions in trunk
- delete tag "latest"
- tag v2.0 etc (or use dates as version number)
- recreate tag "latest"


When referring to the 1.0 tagged version, one always get the "frozen"
1.0 version of the files.

One can always fiddle around with the tags, but that would be logged,
and I'd argue we don't really need an immutable bit.



> This would be rather important for preserving online versions of those
>advisories that are linked from a current compilation.

I'd suggest they should be included (zipped) in the compilation, not just
linked. While the online JIRA tool comes in very handy, it is only a tool,
and as far as OASIS is concerned, the work has to end up in the OASIS
repository anyway...


I wouldn't focus too much on the tooling right now. While I do agree that
a good tool makes life easier, a few scripts and keep-it-simple tricks
with filename or directory structures will probably do

Bart
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php