Community
Participate
Working Groups
I need to create a java project containing several cvs modules. It is possible to create a project with eclipse and use eclipse to check the cvs modules into the project. But if I use commandline cvs to check out the modules in one directory, create a new java project in eclipse using the directory as workspace, the share command doesn't notify that the subdirectories are already cvs modules. So eclipse only offers to create a new single cvs repository for all subdirectories, which of course is not what I want. The share operation should be fixed to recognize such projects. It is possible to circumvent the problem by manually creating a CVS subdirectory in the project main directory and adding the Entires, Repository and Root files, where Entries should list the subdirectories, Repository must contain 'CVSROOT/Emptydir' (without quotes) and Root the cvs root (I don't know whether whis works if the modules have differen cvs roots, in my case the cvsroot is the same for all modules). With such a CVS directory eclipse recognizes the existing cvs modules and the share operation works as expected.
For feature requests of this nature, please provide a more detailed description of what you did, what happened and what you would like to see happen. In this case, we need a more concise description of how you set up the project using the command line before importing it into Eclipse. Please reopen this bug and provide all the steps so we can reproduce the failure (otherwise we'll just pick a set of steps that work and close the bug as WORKSFORME;-)
Project1: cd c:\ cvs co project1 If I create a new Java project in eclipse pointing to c:\project1 I can use Team->Share and Eclipse notes that project1 is already a cvs repository and everything works as expected (I can use the Team commands for cvs operations on the files in project1) Project2: cd c:\ md project2 cd project2 cvs co module1 cvs co module2 A new java project pointing to c:\project2 can't connected to cvs via Team->Share since Eclipse doesn't recognize module1 and module2 as cvs modules. Project3: cd c:\ md project3 A new java project pointing to c:\project3 can be populated with module1 and module2 from the cvs repository view within Eclipse by checking them out into project3. This (and the workaround I gave in the first bugreport) proves that eclipse can handle a single project containing several cvs modules, but failes to recognize this szenario if I don't use Eclipse to do the checkout like in project2 I hope it is now clear what I want :)
That's what I thought you meant but I wanted to make sure. The way we support this is using Checkout As in Eclipse in the following way 1) Create the Java project in Eclipse 2) Perform a Checkout As on a module in the Repositories view (or use the Checkout wizard from the toolbar in the CVS Perspective). 3) Select the option to checkout into an existing project 4) Select the project from step 1) The Eclipse CVS client then does some magic to share the parent project. It is possible that we could do the same magic on a project share but this is a low priority since we support it using Checkout. If you really feel that it should also be supported on a Share as well, feel free to reopen this bug.
I know the way Eclipse support this szenario (in my second description it is project3). But unfortunatly I can't use Eclipse for checkout. We must use advanced ant targets for checkout, because we need to exclude several files/directories from the cvs modules to get a compilable/working set of source files. Thus I think Eclipse should support this szenario in project share, too.
If you are using Ant, perhaps you can modify the script to massage the CVS meta information as required as well. Another option is to provide a patch;-)
I've stepped through the instructions Michael provided in Comment #3. Eclipse checks out the modules no problem. Now, my situation is a bit unique since I do the following... Create a project PROJ. Checkout module foo into PROJ (so now we have PROJ/foo) Checkout module bar into PROJ/foo (so now we ahve PROJ/foo/bar) Everything seems to work just fine from a checkout perspective. However, I don't have any team sharing functionality. From either the Navigator or the PackageExplorer the Team context menu only ever shows 'apply patch' except when I am on PROJ, in which case it also shows 'share project'. When I open the Team Synchronizing perspective I can only ever get to the 'checkout module' option, which allows me to do what I have already done. I am working in 3.1M4 (Build id: 200412162000). Is this something that should work in 3.1? If this is a 3.1M4 specific issue, let me know and I will report it. I am just not sure if this is even supported functionality.
Re: comment 6: This works for me (at least when foo and bar are remote folders). Are foo and bar defined modules? Anyway, this is a separate issue. However, it is only worth while opening a new bug report if you can identify the steps that will allow me to reproduce the problem (otherwise there is not much I can do). Also, could you try with the latest integration build? That's what I used.
I have a similar scenario as described in reply #2, except my modules come from completely separate repositories that can even be of different types (CVS, SVN) that we want to use in one project. /project/module1 -> CVS:user@localcvs:/cvs/module1 /project/module2 -> CVS:user2@cvs.sourceforge.net:/cvs/sfproject/module2 /project/module3 -> SVN:https://user3@subversion.somesite.com/svnproject/module3 Obviously, the the CVS folder hack doesn't work in this case. It would be great if Eclipse would be able to deal with this scenario, perhaps by allowing Team->Share... on separate directories instead of just the entire project. In our case, we don't want to share the entire project, just the modules. P.S. in case you're wondering, we're using the AntMod build tool (http://www.antmod.org/).
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.
