Subversion was not meant to be used as you are using it.
None the less, if you want to keep a good state in the repo (not have
any unapproved code/docs in it), just have the workers submit docs
that need approval to a /branch (or /pending) and then have the QA
department approve the doc and merge it over to /trunk (or /approved).
On 9/2/07, Pat C <pat.chang1973@gmail.com> wrote:
> Hello,
>
> Our solution to our customer involves a tight integration into
> subversion for document exchange.
>
> The problem is:
> ---------------
> The customer is unwilling to accept our current solution as he needs a
> approval process to be in place before the document is committed into
> Subversion. The approval process is critical for the business to meet
> its regulatory needs. Subversion is critical too, since it helps in
> managing versions and trace of the documents committed.
>
> We would like to use hooks to trap any commit into subversion. The idea
> is to use this event to
> a) get the document(s) commited to go into the approval process, and
> more importantly the document is not to be committed into subversion.
> Otherwise others can get access to a unapproved version through a update.
> b) if the document is approved, then checks for conflicts can be made,
> before the commit. If no conflict, then its checked in, else the file
> originator can be notified to update the document accordingly.
>
> Unfortunately Subversion subversion does not provide
> a) the contents of the file for this hooks for users to view for approval
> b) provide an api where another process acting as a proxy (like our
> solution which plans to sit between svn client / server) which can
> commit the code and not the client
>
> Kindly note :
> -------------
> that I have scanned the previous mails being submitted to this forum and
> others too before posting this question. The main reasoning for not
> providing any of the above 2 are because it can send subversion into an
> inconsistent state. But, with the right api's and data to hooks, I think
> this can be synchronized.
>
> If there is a optimal solution for this problem, then it can scale to
> other areas like approval process for code updates into repository
> instead of a "blind" commit.
>
> Can someone please guide me how I can solve the problem with what we
> have currently with Subversion?
>
> Any inputs / help would be much appreciated as the project has now gone
> into a pause and we are unaware of any other way to progress from here.
>
> Pat
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 3 01:31:48 2007