Community
Participate
Working Groups
This is from the platform-vcm-dev mailing list. The inconsitency is caused by the use of phantom folders to improve sync efficiency. I don't think it causes any problems with the command line client. The concern mentioned below that is of interest is that, on update, there may be a lot of extra work done because of the phantom folders. Eclipse 2.1 I have noticed a strange behaviour when using the "purge empty dir" option. When i checkout a project that has deleted directories they are correctly not checked out but the related CVS/Entries file that is built, still lists them and any following cvs update (all done with -d -P options) do not clean Entries file and still tries to update from those deleted directories producing a lot of useless work when the project has many of them. The same happens if i delete a directory from within eclipse, the cvs update does not clean Entries file from that deleted dir. This looks different from normal cvs behaviour that when said to "purge empty dir" deletes the entry from Entries file and never more bothers with that directory unless you resurrect it somehow. Is that an intended behaviour or is an error? Regards, Gabriele.
*** Bug 37923 has been marked as a duplicate of this bug. ***
I got a question from a user on this; any update on this one?
This item wil not be addressed for 3.0.
That's understandable (should it be marked LATER?), but I guess I was asking if you have any ideas for if/when/how to do this and bug 4876 post 3.0? From what little I know about CVS, I was wondering if it was even feasible.
This bug is unrelated to bug 4876. This bug is not overly difficult to fix but it is not trivial either. Bug 4876 is harder to fix since it is a limitation of CVS.
I think i've found some strage behaviour in Eclipse 3.0.1that seems to be related to this bug. We work with an Eclipse project which contained a folder hierarchy that used to store some files. They were all deleted after some time. The root was also added to the .cvsignore file. But every time a "synchronize with cvs" operation is performed Eclipse seems to somehow "remember" that those folders existed and simply ignores the .cvsignore file including it's files as possible "add" entries. Even the local CVS data ("CVS" directories and its files) are recreated for all folders in the hierarchy, leaving other CVS softwares a little confused (like TortoiseCVS).
*** Bug 43443 has been marked as a duplicate of this bug. ***
This behaviour still exists in 3.1.1 (In reply to comment #6) > I think i've found some strage behaviour in Eclipse 3.0.1that seems to be > related to this bug. > > We work with an Eclipse project which contained a folder hierarchy that used to > store some files. They were all deleted after some time. The root was also added > to the .cvsignore file. > > But every time a "synchronize with cvs" operation is performed Eclipse seems to > somehow "remember" that those folders existed and simply ignores the .cvsignore > file including it's files as possible "add" entries. Even the local CVS data > ("CVS" directories and its files) are recreated for all folders in the > hierarchy, leaving other CVS softwares a little confused (like TortoiseCVS).
There is currently no plan to address this item.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
(In reply to comment #10) > As of now 'LATER' and 'REMIND' resolutions are no longer supported. > Please reopen this bug if it is still valid for you. I'm not sure how to reopen the bug, but it is "still valid" for me. My scenario is that I accidentally commited my "target" directory where all my compiled .class files end up. So I deleted the directory, committed the fact the directory was deleted, and then created a ".cvsignore" file instructing the CVS clients to ignore the "target" directory. Unfortunately, Eclipse does not obey the ".cvsignore" file and attempts to recommit the .class files on every synchronize.
(In reply to comment #11) > I'm not sure how to reopen the bug, but it is "still valid" for me. Done.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
