Community
Participate
Working Groups
M5 We recently moved some source from a directory named "DirectoryOne" to a directory named "directoryone" and then removed all files from "DirectoryOne" in cvs. There seemed to be quite a few differnet scenarios. Scenario #1. When getting the source from cvs, eclipse created 2 folders, "directoryone" and "D_i_r_e_c_t_o_r_y_O_n_e". No warning or error messages were reported. I think a warning should be issued saying why this directory was created. Scenario #2. When getting the source from cvs, eclipse created 3 folders, "DirectoryOne", "D_i_r_e_c_t_o_r_y_O_n_e", and "d_i_r_e_c_t_o_r_y_o_n_e". A warning message was created. There were other modifications of these scenarios but I think the _underlying_problem_ is that the cvs client is first creating the directories and then pruning them if they contain no files. If you prevented the creation of directories that do not contain files in the first place then this problem would not occur because there would only be one version of the directory that contains files.
>>When getting the source from cvs, eclipse created 3 folders, "DirectoryOne", >>"D_i_r_e_c_t_o_r_y_O_n_e", and "d_i_r_e_c_t_o_r_y_o_n_e". Odd, I don't think its us (the client) doing this. Do you have scripts on the server? Boris, please test this case.
There are scripts on the server but they don't perform this function. The only thing our scripts do are perform checkin authorization. My cvs Entries files contains the following entries. I think this is specific to 2.1, 2.0 seems to behave differently and without these problems. D/directoryone//// D/D-i_r_e_c_t_o_r_y-O_n_e_//// D/DirectoryOne_//// D/DirectoryOne//// D/d_i_r_e_c_t_o_r_y_o_n_e_//// A more lightweight solution than detecting if the directory tree has files before retrieving it would be checking for these duplicate resources, like directoryone and DirectoryOne and if detected determine which of the two is not empty and retrieve it - i think this is the most common case and would certainly relieve my problems - otherwise return to the normal behavior.
I seem to recall that there are technical problems with us detecting early enough duplicate directories with one empty. I don't recall the specifics but will trawl old bug reports (Boris, perhaps you can have a look). The adding of underscores in file names is curious. Unfortunately the person who worked on this code is on leave, so we'll need to dig a bit.
RC1 seems to be working now except for a decorator problem now seen in Bug 31806.
Even though it seems ok now, it would be interesting to understand what was happening. In your original test case, in step one, when you moved source from DirectoryOne to directoryone, - how did you do it? I mean, did you do it in a working copy and then committed to CVS (if so, was it in Eclipse or using command line cvs?), or you directly manipulated files in the repository? [Side note linking bugs: See also 7960].
I am not really sure to be honest. I wasn't the one that submitted the change and at our dev shop we use eclipse, wincvs and cygwin cvs. I'd say the most likely was via an eclipse commit since that is the predominant client used to access the repository.
Unfortunately, it is the clients responsibility to prune empty directories. Therefore, special handling was added to support the case mentioned by the reporter on case insensitive platforms (i.e. directory rename containg same characters but different case). However, the user should never see this as the checkout/update code only uses the alternate directory name during the operation. The fact that it appears mas that the mechanism failed in some way. Do you still get this regularly?
No it stopped happening and is working properly now.
This is happening again in e3m3. In cvs repository view I have: monitorframework monitoringFramework The eclipse cvs entries file has the following: D/m_o_n_i_t_o_r_i_n_g_F-r_a_m_e_w_o_r_k_//// D/m_o_n_i_t_o_r_i_n_g_f_r_a_m_e_w_o_r_k_//// D/monitorframework//// D/monitoringFramework//// and I get the following error from the cvs console: Error: version: cvs server: cannot open directory /cvs/product/version/x/y/z/a/b/monitoringframework: No such file or directory ***
I'd like to add that while this method seems to work pretty well in most cases we have encountered a problem with it which prevents us from checking out a project from out CVS server. The repository contains files with rather long filenames. Those names are generated by an external tool and cannot be changed. Their length can sometimes exceed 130 characters. If you check those out and due to casing problems (Linux server, Windows client) eclipse's "underscore method" gets invoked, invalid filenames will be generated (exceedings NTFS' limit of 260 characters, cf. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/naming_a_file.asp). Maybe you could adapt the code to first determine of the maximum length (taking into account the workspace location as well) of the resulting path and give a more detailed error message to the user? In addition you might consider a less "expensive" way of changing the conflicting filenames. E. g. instead of inserting a "_" between all the characters just insert something like "___" at those points where the casing really conflicts (DirectoryOne becomes Directory___One instead of D_i_r_e_c_t_o_r_y_O_n_e). I think this needs to be addressed for 3.0 final.
Post 3.0
Would it be possible to first execute all incoming deletions? This would at least solve conflicts where the deletion of e. g. "UpperCase" and addition of "uppercase" are part of the same changeset.
Things have changed considerably since this bug has been entered. Deletions are done first and we don't create any funny directories.
