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

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

Hi Dennis,


> 1. ABOUT TAGS
> (...) 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 (...)

Probably, although some tools might not like this:

Advisories/0001/tags/v1.0
Advisories/0023/tags/v1.3
....
Compilation/trunk/Advisories/0001/tags/v1.0
Compilation/trunk/Advisories/0023/tags/v1.3

(both 'tags' and 'trunk' in the Compilation path)


So that would mean carefully copying the tagged Advisories to, say

Compilation/trunk/Advisories/0001/v1.0
Compilation/trunk/Advisories/0023/v1.3


And once we're happy with that:

Compilation/tags/201001



> 2. ABOUT KEEPING IMMUTABLE COPIES ON A TAG BRANCH
> ...
>  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.

Indeed, SVN doesn't care about "tags", "trunk" etc... that's a convention.
Some tools may warn you when checking in on a "tag", but there is no
way to totally prevent it unless one sets immutable bits on the filesystem
level

> (...) Draw a working copy of a newly created tag into a different server
> space that is read-only to all once created....

At certain intervals, we can just grab the whole lot of approved advisories,
add specification boiler plate, basically saying "this is not a spec", approve
it as a CD and have it published on the OASIS docs site in HTML...
That's probably the way we should do it in order to get started

(...)
> 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.

+1



Bart