This could be a good solution, however, the idea of having the files in
different directories (moving for each status) is not really appreciated
here :S
I really appreciated your answer, it is great to have different
point-of-views about this!
On Tue, Nov 27, 2012 at 5:10 PM, Ulrich Eckhardt <
ulrich.eckhardt_at_dominolaser.com> wrote:
> Am 27.11.2012 16:51, schrieb armando.perico.neto_at_usi.ch:
>
> 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 yet with 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...
>>
>
> This looks similar to the way tags for sourcecode are handled. These are
> also immutable (by convention or enforced by a pre-commit hook) exactly to
> be able to refer to a version unambiguously. Similarly, you could restrict
> operations based on paths (draft, review, release) and persons/roles. For
> example, a pre-commit hook could ensure that a document is only copied to
> the release folder if it was previously in the approved folder. While in
> the review folder, only changes to the "approved-by" property are allowed,
> while any change to the content is denied.
>
> Keep in mind that copying or moving (which is currently implemented as
> copy and delete original) is a "cheap" operation (in terms of disk-space
> and time) and it preserves the history of the file, which is probably more
> important to you. That way, looking at a released file's log, you could
> eaily find out when it was released and rewieved and by whom.
>
> I think the most difficult part is putting the intended workflow into
> pre-commit hooks to guide your team plus a bit of teaching for the team
> members.
>
> BTW: If you take a look at TortoiseSVN, it allows diffing of MS Word
> files, which could be very beneficial to you as it allows making small
> changes like spelling fixes without forcing people to make a full review.
> This feature is not implemented in TortoiseSVN but it leverages that some
> word processors supports this, so you could even use it without.
>
> Good luck!
>
> Uli
> ****************************************************************
> **************************
> Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
> Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
> ****************************************************************
> **************************
> Visit our website at http://www.dominolaser.com
> ****************************************************************
> **************************
> Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der
> beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu
> l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder
> anderweitig benutzt werden.
> E-Mails k�nnen durch Dritte gelesen werden und Viren sowie
> nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese
> Folgen nicht verantwortlich.
> ****************************************************************
> **************************
>
>
--
Armando Perico
Received on 2012-11-27 21:13:30 CET