Community
Participate
Working Groups
1. Check out a project from CVS. 2. create a build.xml in it, and put this in: <?xml version="1.0"?> <project name="project" default="default"> <target name="default" description="--> description"> <cvs dest="tmpdir" command="checkout" cvsroot=":pserver:omry@cvs.telmap.com/cvs/telmap" package="CVSTest"></cvs> </target> </project> 3. change the cvsroot to your cvs root, and the package to some module in the cvs root. 4. from eclipse ant view run the default once. 5. refresh the project containing the build file, a new tmpdir directory with the checked out module will appear. 6. run the default target again. it will fail with errors like : [cvs] cvs checkout: Updating CVSTest [cvs] cvs checkout: move away CVSTest/.classpath; it is in the way [cvs] C CVSTest/.classpath [cvs] C CVSTest/.cvsignore [cvs] cvs checkout: move away CVSTest/.cvsignore; it is in the way [cvs] C CVSTest/.project [cvs] cvs checkout: move away CVSTest/.project; it is in the way [cvs] cvs checkout: Updating CVSTest/src [cvs] C CVSTest/src/Test.java [cvs] cvs checkout: move away CVSTest/src/Test.java; it is in the way Needless to say, when starting with a clean slate and running this ant script from the command line (twice), it works fine. I suspect the problem is related to eclipse filters for /CVS directories. I spent half a day trying to figure out whats going on because of this bug!
Move to Platform/Ant
I have not investigated but can the Team team comment/provide insight?
fixed version to 3.0
In some cases, the CVS plugin will detect that the CVS folders being added are from a different repository and will purge them. The CVS command line will not checkout over existing files. One solution would be to purge the directory in the build script before doing the checkout.
one workaround, you mean.. purging them means ofcourse a longer build time, its not a desireable solution..
Another workaround would be to do your build in a directory that is not in the workspace or in a project that is not managed by CVS. The only scenario where CVS directories are purged is when orphaned subtrees are placed inside projects mapped to CVS. This is done to remain consistent with the architectural descision that repositories are acssociated at the project level. In CVS, this means that all CVS managed resources must be managed from the root of the project and, if they are not, they are unmanaged (i.e. CVS folders removed) so that various UI in Eclipse (e.g. decorators, actions) are not fooled. On a side note, I find it a bit strange to check a project out from CVS and then run a build in that project that checks out more content from CVS? Usually, your check out would get all the content you need and then your build would just build it without needing to contact the server.
I have a complex build system, its code just like any other code so it deserves to be in the CVS. my build system is a closed system, meaning you can check out the build, and run it, and it will build fine on any machine. it contains all the depenencies in the project (ant tasks, confguration files), this makes it very portable. I would not like my build to spread files around in the file system anywhere outside its own directory.. the build checks out its files into a temp directory inside its project dir, since I do not want users to commit files which was checked out by the build, the temp directory is in .cvsignore. maybe the purge can honor that and ignore directories which are in .cvsignore? maybe there should some other way to make it ignore it?
That may be possible but I'm not sure when we would get to it. In the mean- time, you could put it in a linked directory within your project. The CVS plugin will not look inside links for CVS information.
filtering files in .cvsignore does not seem to hard for me, if we agree that its a valid behavior, I can try to do it myself and send a patch.
That would be great. I suspect that implementing a first cut would be easy. My concern is that determining if a resource is managed/ignored must be performant as it is used in menu enablment code. When determining if something is managed, we currently do the following checks 1) Is the resource in a linked folder? If so, ignore it. This is fairly fast as links only happen at the project root and are cached 2) Does the file appear in the CVS/Entries file? This may require a disk access but the result is cahced so disk accessing is minimized. To solve the problem mentioned above, another check would need to be done in between the rwo mentioned that will visit each parent to see if the folder is ignored. This can probably be done fast enough in most cases.
Fair enough. I will have a look soon, see if I can make my heads and tails there.. :)
I looked at it, it does not seem like a big deal, but I didn't find the time to fix it yet (I don't want to hack it without first fully understand whats going on there). I will hopefuly get some time soon, and fix it.
*** Bug 48044 has been marked as a duplicate of this bug. ***
*** Bug 80003 has been marked as a duplicate of this bug. ***
this problem no longer bothers me at the moment, and due to lack of time I pull my previous offer to fix it. (clearing the way for someone else).
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.
