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.
Rolf Wilms wrote: > The developers working on the Eclipse CVS client can be contacted via this > mailing list: Funnily enough I don't get much stress from Eclipse itself - the mailing list is presumably helpful enough that people don't have to come to the CVSNT list that often. My rant specifically wasn't aimed at Eclipse directly because of this (although some of my points are indirectly aimed at them as the writers of much of the code). Indeed I often see messages like 'I asked on the eclipse list and they couldn't help' which I don't mind at all. There doesn't need to be constant communication just enough such that bugs get noticed... This takes maybe one person with their foot in both camps able to pass bugs/discussion both ways (for example I don't monitor the Tortoise list, but there are people who pass on problems/feature requests as they occur, which I feel works well). If they don't object I could mirror the eclipse list on the support.* news heirarchy (heck, even the Tortoise list) which makes it a lot easier for me to check as I almost never subscribe to lists these days. > The dialog which pops up in Eclipse when CVSNT is detected with alleged > repository prefix is a warning only. If you click yes, the connection will > be established though. I know that the incompatibility between Eclipse and > CVSNT w.r.t. repository prefixes has been a very common pitfall in the past. > I suppose this is why this dialog has been added. Thus I don't see a need > for CVSNT to pretend it was Unix. Just ignoring the warning in Eclipse will > do too. Seems that now that the repository prefix incompatibility has been > solved, this dialog causes as much confusion as it was meant to avoid... The dialog is in two places. When you initially connect you can indeed click cancel. However later when you synchronise it pops up again and cancelling it fails the entire operation - this why the 'faking' is necessary. If it had just been implemented as a warning with a 'don't warn me again' checkbox then a lot of confusion would have been avoided. Tony -- Te audire no possum. Musa sapientum fixa est in aure. Tony Hoyle <tmh at nodomain.org> Key ID: 104D/4F4B6917 2003-09-13 Fingerprint: 063C AFB4 3026 F724 0AA2 02B8 E547 470E 4F4B 6917