[cvsnt] Being alerted when commit fails due to ACL

[Andrew Dowell]

Hello Arthur

Thankyou for your reply

I will look into your suggestions.  I suppose what we are trying to 
achieve may be similar to the mixing model described in the document.  
All developers branch off HEAD/TRUNK.  When the development is finished 
the branch gets merged back to HEAD.  Therefore the QA process needs to 
be complete before this merge happens to ensure that HEAD is always 
stable.  In only allowing the review manager to be able to merge to HEAD 
this should solve the problem.  We're really just trying to stop an 
accidental check in on HEAD, where the developer thought they were 
working on a branch but were not for some reason.

The message 'cvs server: User AAA is unable to write to ./ReadMe.txt - 
ignoring' is explicit enough, but it relies on the developer to actually 
look at the contents dialog, rather than just the last line (which says 
Success).  Also the developer has the option to automatically close the 
dialog unless there are errors, and therefore these ignore messages 
would almost certainly be missed.  Generally when there is a CVS error 
(where CVS returns a error code) we get red text in the dialog and a 
audible tone.

I'll look into getting support from TortoiseCVS and also into the new 
versions of CVS suite that you suggest.

Thanks again

Andrew

Arthur Barrett wrote:
> Andrew,
>
> >From your brief description - it sounds to me like you are trying to implement a promotion model:
> http://march-hare.com/cvspro/?pdf=u
>
> Please download the CVS Suite 2009 trial which contains detailed instructions on how to do this and a GUI designed for this purpose.  If you have difficulties - contact the sales team via sales at march-hare.com.
>
> If your GUI is presenting a 'commit successful' message and that is confusing your team - please contact the vendor of the GUI.  GUI's should process all the messages from the server not just the return status code.
>
> The commit returns success because the failure of a single file in a multi-file commit does not represent an error.  It may seem logical that if ALL files fail that it should return an error code - but that is not the standard behaviour and would confuse people relying on the current behaviour.
>
> A person reading the message 'cvs server: User AAA is unable to write to ./ReadMe.txt - ignoring' shouldn't think that the commit has been successful...  I think the error message is quite clear - what would you like to 'see'?    
>
> ie: is the problem you are describing :
> * that the error is unclear
> * a GUI hides the error
> * something else
>
> I recommend people using CVS Suite/CVSNT Server to set up an e-mail trigger (or if using Suite - the bugzilla trigger) to track what is ACTUALLY committed.  The bugzilla trigger is especially nice since it attaches the diffs to the bug and allows for easy 'review' - are the changes I intended in what I committed?  The 'reviewer' can then 'promote' based on that information using the promote function in the Suite TortoiseCVS.
>
> We've been wanting to add auditing of 'errors' to the server audit plugin for some time but due to architectural issues it's not been possible.  
> http://customer.march-hare.com/webtools/bugzilla/ttshow_bug.cgi?id=5518&tt=1
>
> With CVS Suite 2009 this has been solved because of the new architecture (this relies on a small proprietary component - so it is not possible in the community edition).  I look forward to adding errorlog to the audit plugin in CVS Suite 2010 - currently due for preview release in June.
>
> The ACL failure messages are not logged anywhere (eg: syslog or the windows event log or some file), and that is the subject of a different feature request (which we are also looking at resolving in Suite 2010).
>
> Regards,
>
>
> Arthur Barrett
>
>
>
>
>
> -----Original Message-----
> From:	cvsnt-bounces at cvsnt.org on behalf of Andrew Dowell
> Sent:	Thu 29/04/2010 5:29 PM
> To:	cvsnt at cvsnt.org
> Cc:	
> Subject:	[cvsnt] Being alerted when commit fails due to ACL
>
> Hello
>
> We use CVSNT 2.5.03 Build 2382 and TortoiseCVS 1.10.10
>
> This query is along similar lines to: 
> http://www.cvsnt.org/pipermail/cvsnt/2008-April/030581.html
> , though there didnt seem to be an answer to that particular thread..
>
> I am wanting to implement ACL's to only let the review manager to check 
> in to HEAD, rather than developers.  I know how to setup the ACL's, but 
> due to CVS treating the check in request as a success, due to is 
> successfully ignoring it, it is possible that people will think the 
> check in is successful when its not.  I have set the reporting 
> preferences to 'LOUD' but this only does so much...
>
> I have been trying to insert a script or something inbetween Tortoise 
> and CVS ie within the precommand, postcommand etc, but I'm not having 
> much luck.  I can pick up that the commit failed on postcommand due to 
> changes in the arguments, but it doesnt look for a returned error code 
> from the script.  Precommand will look for a returned error code, but 
> does not pass through the target branch, where I could then review the 
> ACL's that have been setup and make a decision...
>
> Is there any other options?
>
> Thanks in advance
>
> Andrew
>
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
>
> Upgrade to CVS Suite for more features and support: http://march-hare.com/cvsnt/
>
>
>
>
>
>
>
>
>
>
>
>   

-- 

-------------------------------------------------
Andrew Dowell
FPGA Engineer

         ..Digicom Answers Pty Ltd..
           http://www.fpga.com.au

Phone: (Direct)        :   +613 8740 3149
--------------------------------------------------

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Digicom Answers Pty Ltd, 1 Dalmore Drive, Scoresby Vic 3179, Australia, www.fpga.com.au