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.
Bryce, Please keep this discussion on the newsgroup. > The problem is with the history, not just the log output. > An update -r didn't get the rename right, and a subsequent > commit resulted in the renamed filename being logged as the > "filename" on the branch revision 1.2.2.1. No the problem is with "cvs update -r" and everything else from that point. Clearly "cvs update -r" does not work immediately after a rename in the same sandbox (assumed by the same user). > As defined in the current version of your manual ( > http://www.cvsnt.org/manual/html/Moving-files.html ), > it clearly states "for a rename to be picked up by other clients a > *cvs update* must be issued at the directory level" (note your bold face). Not "cvs update -r". It appears that combination does not work. > I'm trying to be civil here, but your reluctance to admit a > problem is really alarming. In this thread in several messages I have admitted that "cvs update -r" immediately following a rename does not appear to work (based on your provided information). I also have stated that this is not a "common case" and whilst you have clearly stated it is documented in the manual and is important to you noone else on the newsgroup has chimed in to say it is important to them, and the lack of a bug report on it in 2 years indicates to me it is not a common practice. Again - your original report indicated two users, two sandboxes one on trunk one on branch, a rename in trunk followed by a cvs update on the branch sandbox gives the wrong filename. This is not happening, what you are describing is an error, but a different error. > It is this kind of treatment by the core developers and maintainers > that pushes people to other solutions. This is an open source project. If you require a feature or a fix you can make the change to the source and submit it and we will most likely accept it. I am admitting it is a problem, and if noone else fixes it I most probably will. But I prioritise my time according to my evaluation of priorities. > I've consistently advocated CVSNT to every developer I know as > a solution that's actually better (more featureful and powerful) than > newer, supposed cvs replacements. And I thank you for that, and agree with your opinion. > My motivation to stick with it has taken a serious blow. > I know, understand, and accept the implications of using > "experimental" features. It's the treatments that really chaps my hide. As you may be aware we've had several go's at trying to get the latest improvements into CVSNT, and eventually decided that a partial rewrite was the only way to create a really seamless set of features (including rename). Therefore work on features such as rename is mostly going on in the EVS project and CVSNT is about stabilising the existing feature set and adding incremental improvements. Regards, Arthur Barrett