No subject

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'?   =20

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. =20
http://customer.march-hare.com/webtools/bugzilla/ttshow_bug.cgi?id=3D5518=
&tt=3D1

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:=09
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:=20
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=20
in to HEAD, rather than developers.  I know how to setup the ACL's, but=20
due to CVS treating the check in request as a success, due to is=20
successfully ignoring it, it is possible that people will think the=20
check in is successful when its not.  I have set the reporting=20
preferences to 'LOUD' but this only does so much...

I have been trying to insert a script or something inbetween Tortoise=20
and CVS ie within the precommand, postcommand etc, but I'm not having=20
much luck.  I can pick up that the commit failed on postcommand due to=20
changes in the arguments, but it doesnt look for a returned error code=20
from the script.  Precommand will look for a returned error code, but=20
does not pass through the target branch, where I could then review the=20
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/