Hi Andy,

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








________________________________
From: Andy Levy [andy.l...@gmail.com]
Sent: 27 November 2012 15:24
To: Perico Neto Armando
Cc: users@subversion.apache.org
Subject: Re: File status control



On Tue, Nov 27, 2012 at 8:44 AM, 
armando.perico.n...@usi.ch<mailto:armando.perico.n...@usi.ch> 
<armando.perico.n...@usi.ch<mailto:armando.perico.n...@usi.ch>> wrote:
Guten Tag Thorsten!

that's what I've imagined.

We actually have to use SVN as a sort of configure management system. I am 
currently writing a pre-commit hook so we can control it without using the 
"svn:properties" (we've decided to add a flag on the commit messages with the 
current file statuses. It doesn't look much elegant but this was the only way 
we've managed to have it "user-friendly"//acceptable for the developers.

It seems weird though that subversion has not a native way of doing so, people 
from the "quality departments" love this sort of functionality.


I never consider "file" statuses for the items in my source code repository - 
only the status of the entire project, via my tags & branches.  Releasing 
individual files to an environment (at least for software my team and I have 
built) would just lead to large amounts of confusion, and broken releases.

Reply via email to