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 firstname.lastname@example.org.
I have a question about the way in which cvsnt handles case-sensitivity on Windows (I know Windows is a case-insensitive filesystem). By way on an example, here is my question: If we have a CVS repository consisting of the following:- projects/ -> CASE/ -> A_File.c (tag=projA) -> case/ -> B_File.c (tag=projB) -> parent.c (tag=projA, projB) When executing "cvs checkout -r projB projects" on a Windows system I get the follow projects/ -> CASE/ -> B_File.c (tag=projB) -> parent.c (tag=projB) As you can see, the "B_File.c" has ended up under the "CASE" folder rather than the "case" folder (even though there are no files under CASE that are tagged for "projB). Whilst this is not a problem on a case-insensitive system, it does cause a problem if you then modify that file and try to check it back in. It will fail because no "B_file.c" exists in the repository under the "CASE" folder. To me, the behavior of CVSNT should be consistent with the case-sensitive nature of the repository. In other words, CVSNT should only create folders, using the correct case-sensitive name matching the folder in which the file(s) resides, when it encounters a file that matches the checkout criteria. In the example above, it looks like CVSNT is performing a case-insensitive comparison of folder names (and is therefore failing to update its copy of the folder name to match that of the folder in which the file it has found resides) on checkout, but is performing a case-sensitive comparison on checkin. Is this a known problem/limitation? Is this behavior still present in EVS? Is there any way to change the behavior by, say, the use of a command-line switch? Regards, Andrew