Considering that I won't be able to suggest a DMS (which would be the
correct solution as suggested by Andy),
what would do is:
1) In order to attach the status of the document and allowing the users to
easily see the current status and the previous values, I would probably
require a flag i.e.: [status=XXX] on the commit logs
* with svn:templates is easy to always have the default status
automatically there
* if no status is provided, the system shall understand it as the default
* The svn:properties would be correct option here, but with TortoiseSVN, it
seems not to be possible to have a view with the "history of changes".
2) To control the change of status, I will probably suggest a pre-commit
hook
2.1) the rules (authors permissions vs. rules for the change of status
) I am thinking in storing on the root svn directory of each project. i.e.:
in a folder .config/ At every commit, the precommit hook would check these
values for blocking or allowing the commit
It looks (and it is) "dirty", but it seems to have very low impact for the
users. They could still keep using TortoiseSVN as client for all the
operations and no need to learn new interfaces and processes.
I will keep thinking about it. In any case, thanks a lot for the
suggestions, they have been very helpful.
On Tue, Nov 27, 2012 at 9:27 PM, Armando Perico <pericona_at_usi.ch> wrote:
> Yes, use trac could be an option too. I will definitely check the pros and
> cons for that!
>
>
> On Tue, Nov 27, 2012 at 8:02 PM, Les Mikesell <lesmikesell_at_gmail.com>wrote:
>
>> On Tue, Nov 27, 2012 at 9:51 AM, armando.perico.neto_at_usi.ch
>> <armando.perico.neto_at_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
>> lesmikesell_at_gmail.com
>>
>
>
>
> --
> Armando Perico
>
--
Armando Perico
Received on 2012-11-27 21:45:23 CET