This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Every time I check out my module on a branch, I get errors during the auto refresh. This is using the internal cvs client. A colleague has reproduced this on a different machine. We were both able to check out the main line with no issues. On both of our machines the CVS/entries file looks correct. The only difference between the NB4 entries file and the Netbeans 3.5.1 entries file is that the NB3.5.1 file has pruned empty directories in it. The NB4 version does not. The error happens on many files. (Maybe one for every directory ...?) Many errors are because files that it thinks are directories are not: (build.xml is an ant script) Error: lock directory for `/ocie/dev/cvs-j/java/support/ ant/build.xml' (/ocie/dev/cvs-j/java/support/ant/ build.xml/#cvs.lock): No such file or directory The ones that are directories fail with a weird path: This would be a valid path, but notice that JavaOcie (a module name) is not resolved to the java directory like in the previous example. Also notice the appearance of a '.' all of a sudden Error: failed to create lock directory for `/ocie/dev/ cvs-j/./JavaOcie/src/dsi' (/ocie/dev/cvs-j/./ JavaOcie/src/dsi/#cvs.lock): No such file or directory Here is another file that errored. Notice that the name is wrong. Correct name: dsi/core/crypto/ DCipherAlgorithm.java. The file it is complaining about is CipherAlgorithm.java not DCipherAlgorithm.java Error: cvs-1.11.1p1-SUNOS-5.6 server: failed to create lock directory for `/ocie/dev/cvs-j/java/src/dsi/ core/crypto/CipherAlgorithm.java' (/ocie/dev/cvs- j/java/src/dsi/core/crypto/CipherAlgorithm.java/ #cvs.lock): No such file or directory cvs-1.11.1p1-SUNOS-5.6 server: failed to obtain dir lock in repository `/ocie/dev/cvs-j/java/src/ dsi/core/crypto/CipherAlgorithm.java' cvs-1.11.1p1-SUNOS-5.6 [server aborted]: read lock failed - giving up My CVS/entries file for the previous example is: D /CipherAlgorithm.java/1.1/Fri May 21 21:19:34 2004//TRELEASE_04_02_BRANCH /CryptoSession.java/1.1/Fri May 21 21:19:33 2004// TRELEASE_04_02_BRANCH /DCipherInputStream.java/1.2/Mon May 24 21:58:10 2004//TRELEASE_04_02_BRANCH /DCipherOutputStream.java/1.2/Fri May 28 15:52:11 2004//TRELEASE_04_02_BRANCH /DCryptoException.java/1.1/Fri May 21 21:19:33 2004//TRELEASE_04_02_BRANCH /Muddler.java/1.2/Mon May 24 21:58:09 2004// TRELEASE_04_02_BRANCH /params768/1.1/Fri May 21 21:19:33 2004// TRELEASE_04_02_BRANCH
*** Issue 52295 has been marked as a duplicate of this issue. ***
I am struggling to understand why you chose the 'contrib' component here. Is this specific to some experimental module you downloaded? Probably you wanted 'javacvs'?
Sorry, I must have missed the component box, or it go flipped when I accidently resubmitted the form. I did not intend for this to be associated with contrib. However, I don't know if it is javacvs or not. It also has problems with the command-line client. The errors are different, but they are there. And the result is the same. No CVS access for these files. Just for kicks, I checked out my branch using NB4, closed NB4, started Wincvs, checked out my branch with this, deleted the NB4 JavaOcie directory and replaced it with the JavaOcie directory that wincvs made. I then restarted NB4. The files came up as local, but I could do a refresh. The refresh worked, and now it looks like I am in business again. Since it doesn't work with either the built-in client or the command line client, I am going to guess that this should be in vcscsv core, so I will take my chances and assign it there.
A clue! This test was using the built-in cvs client. It looks like it is not putting the CVS directory in directories with just directories in them (i.e. no files). Also, in at least some of the directories with files (there are too many to check), it put the first file in the directory in the REPOSITORY file. So instead of the correct REPOSITORY line "java/ files" it has "java/files/activation.jar" Fixing the REPOSITORY file fixes the directory. However, I don't know a way to fix the directories that don't have a CVS directory in them.
VCS owners please evaluate.
It looks like it can be a bug of javacvs library. However, we did not encounter problems like this ever before. What version of CVS server do you have? Can you please run NetBeans with -J-DcvsClientLog=C:\Temp\log (or other path to some temporary file). You can add this option to etc\netbeans.conf in your user directory. Please run the checkout then and attach here the created log.in and log.out files. Thank you.
A similar bug was discovered in issue #52331. It looks like the checkout works wrong when CVS/ folder is not yet created.
This is a bug in the library for sure - reproducible when PRE_CHECKOUT_CREATE_CVS_FOLDER is removed as a pre-command from CHECKOUT_COMMAND command. It creates CVS/Repository file with the name of the file that is checked out as the first one.
Mark, no need to attach the logs, I've reproduced the bug.
Fixed in trunk: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/admin/StandardAdminHandler.java,v <-- StandardAdminHandler.java new revision: 1.34; previous revision: 1.33
Is this going to be fixed in 4.0? If not, is there a work-around for this issue? This is a major inconvienence, especially in a team environment. I would hate to have to explain to everyone how to use WINcvs to get netbeans to check out a project on a branch. I would think that you guys develop in netbeans as well. Why has this not been an issue for you or anyone else?
This actually does not really work with a winCVS checkout. The winCVS does not put in the "tag" file in the CVS directory. This causes updates at certain levels of the directory tree to update on the wrong branch. PLEASE fix this in 4.0!
It's too late for 4.0. But I will put a fix to hotfixes. But it seems that there is still some other problem, which occurs only when a branch is checked out. I'm going to test that more thoughoutly. We use NetBeans for CVS operations, but do not perform checkout from a branch much...
Well, it's true that there is still some problem in administrative files. In some folders there is not the CVS folder at all, In other folders there is not full listing of versioned sub-folders in CVS/Entries. But WinCVS does put Tag file in CVS/ folders. At least version 1.3 does this.
*** Issue 52537 has been marked as a duplicate of this issue. ***
This bug is not in NetBeans 3.6, but is in NetBeans 4.0. I've made a diff between release36 and release40 in javacvs module and I'm inspecting the differences. Hopefully I'll find the change that is responsible for this soon...
Wery likely caused by issue #42267. As a workaround, checkout the trunk and update to the desired branch.
It seems that this issue is more important then issue #42267, therefore issue #42267 was rolled back, which seems to fix this: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/response/ClearStaticDirectoryResponse.java,v <-- ClearStaticDirectoryResponse.java new revision: 1.15; previous revision: 1.14
QE: can you please test whether the checkout with built-in client works fine in trunk after this change? (Both checkout of trunk and of branches.) If yes, we can put this into hotfixes, untill we find the proper fix of issue #42267. Thanks.
I've just tried the hotfix, but the error is still there CVS when I create a branch and check it out I am still getting this error Command "Status" has failed. Execution string: The error output follows, check Runtime for the full output of the command. cvs server: Examining star cvs server: failed to create lock directory for `/usr/local/repository2/StarUtil/Ant.xml/star' (/usr/local/repository2/StarUtil/Ant.xml/star/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/usr/local/repository2/StarUtil/Ant.xml/star' cvs [server aborted]: read lock failed - giving up
This is not yet fixed on hotfixes update center. This issue is not yet verified. Peter, can you please verify this issue in dev builds? Thanks.
Verified in 200501021900.
*** Issue 53625 has been marked as a duplicate of this issue. ***