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.
Windows imposes a 260-character limit on full file paths including drive and final NUL. Many files in nb.org CVS are already approaching that; for example, the worst is uml/core/test/unit/src/org/netbeans/modules/uml/core/reverseengineering/reintegration/umlparsingintegratortestcases/attributetest/AssignValueToFinalVariabletest/FinalVariableInitializationWithinMethodTest.java at 209, leaving only 50 characters for e.g. C:\....\my_checkout above which CVS commands will fail. The Mercurial import triggers some problems here, as Mercurial storage paths expand a bit when there are capital letters or underscores in the original: http://www.selenic.com/mercurial/bts/issue839 and the result can make it impossible to unpack a Hg repo on Windows, e.g. $ tar -xvf main.tar tar: main/.hg/store/data/o.n.m.uml/test/unit/src/org/netbeans/modules/uml/core/reverseengineering/reintegration/umlparsingintegratortestcases/attributetest/_assign_value_to_final_variabletest/_final_variable_initialization_within_block_test.java.i: Nelze open: File name too long I have collected a list of files in nb.org CVS which produce repository paths even longer than the longest paths we used in CVS and which are therefore immediate problems. (There are thousands more files which are longer than they perhaps should be but which are not likely to pose problems to people already using CVS successfully.) These issues need to resolved quickly; otherwise it is difficult to test Hg operations on Windows. With the current state, the longest root prefix you can use is likely to be e.g. C:\devel\myrepo which is pretty limiting.
For reference, found using command: find */.hg | ruby -n -e 'BEGIN {@trans={}; open("main/nbbuild/translations").each_line {|l| parts=l.chomp.split "//"; @trans[parts[1]] = parts[0]}}; if (!/^.{0,209}$/) then gsub!(/_([a-z_])/) {|c| $1.upcase}; gsub!(%r{^([a-z]+/)\.hg/store/data/(.+)/([^/]+)\.i$}) {|all| repo=$1; path=$2; file=$3; puts "#{@trans[repo + path]}/#{file}"}; end' | sort
There is no exact maximum for CVS file lengths - problems will depend on the path length used for the root of a checkout, and the chars added by Hg will depend on the number of [A-Z_] in the path - but for the files that I filed bugs for it would be good to trim off at least 30-40 characters. In most cases the long files are tests whose names can simply be abbreviated, e.g. uml/core/test/unit/src/org/netbeans/modules/uml/core/reverseengineering/reintegration/umlparsingintegratortestcases/constructortest/ConstructorAttributeCallUsingThisKeywordTest.java could just as easily be named something like uml/core/test/unit/src/org/netbeans/modules/uml/core/reverseengineering/reintegration/umlparseintgtor/ctor/CtorAttrCallUsingThisKwdTest.java saving 41 characters.
All fixed with the exception of 9 files in enterprise/openesbaddons/contrib-imola in CVS, which anyway go to the misc repo. Also have fixed import script to just skip over any files with paths too long (above 206 chars in store path) and produce a report about them. So good enough for now.
Long Path Tool can be the best solution, I will say.