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.
[ BUILD # : 200808051401 ] [ JDK VERSION : 1.6.0_04 ] I had checked out a branch using NB 6.1. Then, I installed a daily build and imported settings and as part of my work, I had to switch to trunk. Once the operation was supposedly finished, I noticed the versioning labels were still there. I looked at the output and only a few files had been replaced with their trunk version. Then I tried doing it again, and other files were replaced, but labels remained for most folders. I went back to NB 6.1 and tried to do the same thing and it simply worked. Hadn't I had versioning labels turned on, I could have messed up my production environment. This is a very serious issue.
let me summarize your usecase 1, checkout a source code from a branch with NB 6.1 2, install and start NB 6.5, let it import the settings 3, update the source code to trunk version -> sources are not updated correctly
That's it.
Created attachment 66939 [details] CVS logs and messages file
Here are the logs for a failed attempt.
I tested ... Product Version: NetBeans IDE 6.5 Beta (Build 200808101001) Java: 1.6.0_10-rc; Java HotSpot(TM) 64-Bit Server VM 11.0-b13 System: Linux version 2.6.24-19-generic running on amd64; UTF-8; en_US (nb) steps : - checked out sources - updated some files and created branch - commit changed files into the branch - switched to trunk -> everything works as expected as well as : - start NB 6.1 - checkout branch - shut down IDE - start Beta - import settings - switch to trunk -> everything works as expected Decreasing the priority for now, not a stopper for Beta.
Can't reproduce either.
There is no indication of an error in the logs either.
Besides switching to branch from a clean installation (without importing settings from 6.1) - which I will do shortly -, what else can I do to help you track this?
Created attachment 67032 [details] CVS logs without importing settings from 6.1
Created attachment 67033 [details] CVS logs without importing settings from 6.1
Created attachment 67034 [details] CVS logs without importing settings from 6.1
Created attachment 67035 [details] CVS logs without importing settings from 6.1
Created attachment 67036 [details] CVS logs without importing settings from 6.1
Created attachment 67037 [details] CVS logs without importing settings from 6.1
Created attachment 67038 [details] CVS logs without importing settings from 6.1
Created attachment 67039 [details] CVS logs without importing settings from 6.1
Created attachment 67040 [details] CVS logs without importing settings from 6.1
Created attachment 67041 [details] CVS logs without importing settings from 6.1
Created attachment 67043 [details] CVS logs without importing settings from 6.1
Created attachment 67044 [details] CVS logs without importing settings from 6.1
Created attachment 67046 [details] CVS logs without importing settings from 6.1
Created attachment 67047 [details] CVS logs without importing settings from 6.1
Created attachment 67048 [details] CVS logs without importing settings from 6.1
Created attachment 67049 [details] CVS logs without importing settings from 6.1
Created attachment 67050 [details] CVS logs without importing settings from 6.1
Created attachment 67051 [details] CVS logs without importing settings from 6.1
Doesn't seem as broken as my first attempt (maybe not at all), but versioning labels have not been removed.
Can't find any error in attached cvs logs. Could you please verify CVS/Entries file whether labels are (not) set. ... /build.xml/1.1.1.1/Tue Sep 26 07:27:24 2006//T<(BRANCH)TAG_NAME> ... And CVS/Tag Switching Trunk <-> Branch works fine for me. Does this happen randomly or you've experienced it for special cases (file types and so on)?
Created attachment 67284 [details] Entries for a specific folder
Created attachment 67286 [details] Tag file for a specific folder
It is reproducible every single time. Files are attached. As you can see, it's pretty broken.
Peter, can you please take a look at this now? Thanks a lot!
I can reproduce it now just using an external project folder. See this snippet from project.xml: <properties> <property name="project.dir">../../xxxxx/yyyyy</property> <property name="ant.script">${project.dir}/build.xml</property> </properties> where yyyyy is the project folder. If I have the nbproject folder at yyyyy everything works. I am setting as P1 since it can produce data loss. I can suggest two options to solve the problem: 1-Fix the cvs support in this scenario; 2-Forbid external project folders, which means a) the wizard won't create them; b) the IDE wouldn't open this kind of project displaying a warning about it instead. So, letting it open the project and then produce data loss is not an option. Regards
What kind of project do you user? I've tried free-form project and project with existing sources and couldn't reproduce it. Anyway, the attached "Entries" file seems to be corrupted (some files with sticky tag and trunk version - merge of two or more Entries files), have you modified it, or it's the result of "cvs | switch to"? And finally the result of "cvs switch": Michael said that it there was an indication of wrong labels only, not the content of files. I've verified it in NB 65. I will test in 61. Anyway, can you switch to NB 65 ;-) as this issue has [65cat] prefix?
> What kind of project do you user? Free-form with existing sources. project.xml: http://www.netbeans.org/nonav/issues/showattachment.cgi/67023/project.xml > Anyway, the attached "Entries" file seems to be corrupted (some files with sticky tag and trunk version - merge of two > or more Entries files), have you modified it, or it's the result of "cvs | switch to"? The result of it. > And finally the result of "cvs switch": Michael said that it there was an indication of wrong labels only, not the > content of files. Not really, I said maybe. After checking, it is indeed broken. > I've verified it in NB 65. I will test in 61. Anyway, can you switch to NB 65 ;-) as this issue has [65cat] prefix? I've tested it using NB 6.5. The daily build number has been mentioned already. What makes you think I've used NB 6.1?
Sorry ;-) I've just seen a lot of 6.1. Anyway, it would be really helpful and it can also make things come faster if you could send me (privately) at least some project's files. (nbproject/project.xml, and appropriate directory with corrupted CVS/Entries, ...) Can't it happen that there are sources from different CVS repositories at the same directory level in your working copy?
> Anyway, it would be really helpful and it can also make things come faster if you could send me (privately) at least > some project's files. (nbproject/project.xml, and appropriate directory with corrupted CVS/Entries, ...) project.xml has been sent already. I will send you one dir with a bad CVS/Entries file. The first one I found is hundreds of MBs large. > Can't it happen that there are sources from different CVS repositories at the same directory level in your working copy? Not the case. And it works in 6.1.
BTW, just found out that if I use the Favorites view to perform the operation, it works.
So from within "Favorites" view it works. And what about "Files" view? Perhaps related to source groups. Jesse, could you please evaluate?
Doesn't work from Files.
Broken project dir sent privately.
What am I to evaluate? The maintainer of freeform projects is Milan Kubec. But the onus is on the CVS module maintainer to determine what is going wrong; if there is a specific problem in the freeform project module independent of CVS support, e.g. an incorrect list of source groups being reported, it can be reassigned with an explanation of that problem. BTW try the NetBeans Metadata Inspector module (dev AU) to quickly see what various queries say about a project.
BTW, CVS -> Diff doesn't work as well, even though the Output tab shows some modified files.
We are investigating it.
BTW, why is this issue incomplete? Is there anything Michael is supposed to give us? Are we waiting for something? I am removing the keyword because it looks like the ball is on our side now.
Are all these true? 1) The switch does NOT work when you invoke CVS/Switch from Project node context menu 2) The switch DOES work when you invoke CVS/Switch from a folder's popup menu in Favorites view (for example cotacao/conf/hibernate folder) 3) The switch DOES work when you invoke CVS/Switch from a package node (or other, non-project node) popup menu Is the behavior consistent? (I mean, every time you try it, the same files are not switched correctly) If so, I will send you a patched jar file with more logging enabled to see what is the problem with this particular project.
> 1) The switch does NOT work when you invoke CVS/Switch from Project node context menu True. > 2) The switch DOES work when you invoke CVS/Switch from a folder's popup menu in Favorites view (for example > cotacao/conf/hibernate folder) True, though I always try to switch using the equivalent to the project's root node. > 3) The switch DOES work when you invoke CVS/Switch from a package node (or other, non-project node) popup menu True (though I hadn't tested it before). > Is the behavior consistent? (I mean, every time you try it, the same files are not switched correctly) Well, it's consistent in the sense it always fails and labels are left for all folders. Never actually tried to see for which files it fails, though testing it right now shows that for the two folders I've actually paid attention last time, it has failed again. > If so, I will send you a patched jar file with more logging enabled to see what is the problem with this particular > project. Will attach.
Created attachment 67834 [details] messages.log for modified module
Waiting for further instructions.
Ok, so I think we are dealing with two issues here. CVS issue is that we are probably incorrectly handling one server response while switching branches. The other issue here is that project is telling CVS that it only contains the .cvsignore file. From your log (see below) - the project effectively contains only .cvsignore file, all other subfolders are not part of the project. So the correct behavior from CVS point of view is to only switch the branch for that one file and ignore all others. I assume that this is an issue as well. If you agree I will fix the bug on my side and reassign to project guys afterwards. --- Root files: C:\projetos\rio_branco\cotacao / false --- Excluded files: C:\projetos\rio_branco\cotacao\grinder / false C:\projetos\rio_branco\cotacao\src / false C:\projetos\rio_branco\cotacao\target / false C:\projetos\rio_branco\cotacao\project.properties / false C:\projetos\rio_branco\cotacao\build.xml / false C:\projetos\rio_branco\cotacao\desktop_build.xml / false C:\projetos\rio_branco\cotacao\resource / false C:\projetos\rio_branco\cotacao\producao / false C:\projetos\rio_branco\cotacao\project.xml / false C:\projetos\rio_branco\cotacao\master_build.xml / false C:\projetos\rio_branco\cotacao\build.properties / false C:\projetos\rio_branco\cotacao\doc / false C:\projetos\rio_branco\cotacao\lib / false C:\projetos\rio_branco\cotacao\xdocs / false C:\projetos\rio_branco\cotacao\build.properties.sample / false C:\projetos\rio_branco\cotacao\conf / false --- Files: C:\projetos\rio_branco\cotacao\.cvsignore / false
All other dirs are part of my freeform project, so definitely if the project infrastructure tells you they are not, it is wrong. Again, it works like a charm in 6.1 and previous releases, so it is related to some change in 6.5.
Fixing on my side: 40310418a471 Reassigning to project guys, see last few comments, it seems that misterm's project is broken in 6.5.
ant/freeform specific?
Created attachment 67949 [details] Example project.
Please unpack the attached example project ("freeform.tar.gz") and open freeform/make/prj/ project in the IDE. There are three source roots under the project root: java, java2 and inner. java and java2 are "external" (not under freeform/make/prj), inner is "inner" :-). The project is obviously not the owner of java and java2 source roots from the FileOwnerQuery point of view (watch the project name in the main window title), which is quite a big problem. May also be the culprit of issue #143313. (I hope the project.xml is correct...)
Please disregard my last comment - a generic/untyped source root is missing in the example project.xml. Sorry for confusion.
what specifically is the data loss here with regard to projects? (after cvs fix) re: > <properties> > <property name="project.dir">../../xxxxx/yyyyy</property> > <property name="ant.script">${project.dir}/build.xml</property> > </properties> > > where yyyyy is the project folder. If I have the nbproject folder at yyyyy everything works. I don't know the specific of freeform projects but the general agreement for external source root is that they are useful. for some people. but it's basically the user's responsibility to maintain the consistency of the data, especially the relative path to project source roots..
> what specifically is the data loss here with regard to projects? (after cvs fix) As far as I understand, CVS still causes data loss possibly due to some change in the way freeform deals with external source roots. > I don't know the specific of freeform projects but the general agreement for external source root is that they are > useful. for some people. but it's basically the user's responsibility to maintain the consistency of the data, > especially the relative path to project source roots.. There is *nothing* wrong with the project configuration. I have this project configured since NB 4.1 and it works on 6.1. Something changed somewhere and completely broke these projects. They open, their nodes are shown correctly on Projects and Files, but things like CVS cause data loss. Please let me know if you need more information.
Integrated into 'main-golden', available in build *200808201401* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/40310418a471 User: Maros Sandor <msandor@netbeans.org> Log: #143323: Checked-in and New-Entry responses did not take the globalOptions.excluded files list into account
Milane, can you please evaluate this issue? If you have additional questions, need any other cooperation just ask for it. Michael is willing to do whatever is needed to help fix this obvious showstopper. Thanks!
I can just restate the question from mklient: > What specifically is the data loss here *after cvs fix* with regard to projects?
It seems that I will need more info to resolve the issue: - what is physical structure of files in CVS repository, are source roots and project folder all under one folder in CVS? - was the project imported to CVS via NetBeans IDE?
I've been trying 200808241401 for a while and I couldn't reproduce it yet. Hopefully it's gone now. I will let you know after a couple of days.
Updates are failing now. I had a trunk check out and tried to update it. One file was reported as removed in the Versioning output tab. However, a few hundreds of files had been modified. I've switched to 6.1 and update worked. NB build: 200808241401. Do you consider this part of this issue or should I file a new one?
Do not file new issue, all your issues seems to be related some particular project setup. Repeating my questions: - what is physical structure of files in CVS repository, are source roots and project folder all under one folder in CVS? - was the project imported to CVS via NetBeans IDE? Thanks
> - what is physical structure of files in CVS repository, are source roots and project folder all under one folder in > CVS? For several (hard to explain) reasons, only source roots are in CVS. The project folder is not versioned and locally external to the directory that contains all source roots. > - was the project imported to CVS via NetBeans IDE? It's been 4 years now, I can't remember, but I guess not.
I'm trying hard but I'm not able to reproduce on current dev build. I created project (not using NB IDE) consisting of three source roots with sources, one test source root, libs folder with jars required for compilation and build.xml file. I imported all this to CVS on command line. Then I started IDE and created freeform project pointing to the project checked out from CVS, I let the project folder be created in different folder than versioned sources. Then I tried to create couple of branches and have been swithing among them and trunk and it worked well, including versioning labels. Please could you try to reproduce the issue with clean userdir without importing anything?
I tried again (the same scenario: project sources in CVS externally from nbproject; 4 source roots; changing branches) but still the same result - cannot reproduce. misterm, do you have any news? Would you be able to create self containing testcase for this problem? And also would you try to create the project again but in NetBeans 6.5 (the project is not versioned, so it might be easily possible)? Thanks for cooperation. I'll lower priority to P2 until there is reproducible testcase for the problem or at least clear identification of the problem.
I've being using 200809120201 for a day now. It seems to work properly. I will use it for a week and then give my final word about it.
Marking as INCOMPLETE until reporter says if if it's really reproducible after some time of real work with IDE.
I consider it officially fixed. If it happens again, I will reopen this issue.
Thank you very much Michael for your help with this issue!