Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Andrew,
I believe what you are using is the old 'flying fish' model. It's a sound strategy, but only if you can quantify the business benefit you are gaining by having the manager sit there and do all the merges to HEAD. What do you gain?
Typically I see this requirement when the 'gain' that is sought is some control over or ability to track which changes are making it into a release. This requires change control (not version control) which requires the use of 'user defined change set numbers'/'bug numbers' - and works best when used with a defect tracking tool and integration.
It sounds to me as if your specific technical problem is with TortoiseCVS - please contact the TortoiseCVS newsgroup - or simply enter the feature request directly into the sourceforge tracker:
http://www.tortoisecvs.org/support.shtml
We maintain our own builds of TortoiseCVS for use in CVS Suite, and we are currently submitting patches for/to TortoiseCVS 1.12 RC. I'm surprised that this issue hasn't been raised before. TortoiseCVS already detects some errors (like conflicts during update) and so it should be (relatively) simple to add support for an additional check for ACL messages.
I believe that the TortoiseCVS progress dialog will only dismiss automatically if there were no errors.
Regards,
Arthur
-----Original Message-----
From: Andrew Dowell [mailto:andrew_dowell at fpga.com.au]
Sent: Fri 30/04/2010 12:49 PM
To: Arthur Barrett
Cc: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: Re: [cvsnt] Being alerted when commit fails due to ACL
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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
> 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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs
>
> 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