On Tue, Nov 27, 2012 at 9:51 AM, armando.perico.n...@usi.ch
<armando.perico.n...@usi.ch> wrote:
>
> you are probably right if we think only about code and software projects;
> however, the needs for these features here are to control "documentation
> projects" i.e.: to handle documents for ISOs and IECs standard implementation
> (we pretty much handle .doc files - no need to handle line diffs and merges
> for instance).
>
> Note: An important requirement here is that the path of the document shall
> never change once it has been defined and published internally.
>
> Some uses cases:
> - Only create a "release" versions of the documentation when all the
> documents are with the "approved" status.
> - Only specific author can make revisions
> - A document cannot be "approved" if it has not been "reviewed" and so on...
>
> I am not comfortable yetwith the solution we're planning to use in order to
> solve this, however, it seems to be the solution with less "side-effect" to
> the users (once SVN is already used as a repository system for the documents).
>
> I am still trying to put the ideas together to come up with a good solution.
> I am open to suggestions...
With software projects, a common approach is a name/number convention
for branches and tags, where new/unconstrained work happens on the
project trunk, then when it reaches an appropriate stage it is copied
to a branch for review (and for software, testing) and final changes,
and at least the final/release version is copied to a tag. Part of
the convention is that tags are never changed so can also use them to
snapshot working revisions if you don't like using svn's own revision
numbers - and/or you can use different-named branch trees for
different stages of your review process. You can use subversion
pre-commit hooks to enforce some of your process restrictions - like
who can write to which area, but you may also want an external tool
like trac to follow the process and have a place for commentary and
status tracking.
--
Les Mikesell
lesmikes...@gmail.com
