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.eckha...@dominolaser.com> wrote: > Am 27.11.2012 16:51, schrieb armando.perico.n...@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
