Community
Participate
Working Groups
I have a cvs alias module, which includes a number of directories from another module. To clarify: My repository contains this folder and structure: javaproject/WEB-INF/src/com/mycomp/myproj/Class.java /com/mycomp/myproj/Class2.java /com/mycomp/myproj/stuff/Class.java /com/mycomp/exclude/Class.java /com/mycomp/util/UtilClass.java In my modules file I define a module called 'aggregateproject' like this: aggregateproject -a javaproject/WEB-INF/src/com/mycomp/myproj javaproject/WEB-INF/src/com/mycomp/util !javaproject/WEB-INF/src/com/mycomp/exclude If I check the aggregateproject out using an external cvs client, I end up with this directory structure: javaproject/WEB-INF/src/com/mycomp/myproj/Class.java /com/mycomp/myproj/Class2.java /com/mycomp/myproj/stuff/Class.java /com/mycomp/util/UtilClass.java Which is what I want! Similarly, using eclipse, if I check out the aggregateproject module from the CVS Repositories view using the option of just "Check Out" a project is created with the same directory structure. However, if I use any of the options under "Check Out As...", I end up with this directory structure: Class.java Class2.java stuff/Class.java UtilClass.java This is clearly not what I want. Checking out of alias modules seems to broken when using "Check Out As..."
It could be the case that the -d option is interferring with the module definition. If you check out your module with the command line client using the -d option, what do you get (cvs co -d myProject aggregateproject)?
I've tried the command in the format you suggested from the command line, but it didn't work properly: $cvs co -d :pserver:user@server:/myrepository aggregateproject cvs checkout: No CVSROOT specified! Please use the `-d' option cvs [checkout aborted]: or set the CVSROOT environment variable. Are you sure you didn't suggest the arguments in the wrong order? If I do this: $cvs -d :pserver:user@server:/myrepository co aggregateproject Then the directory structure is correct upon checkout (after logging in, of course). However, this may not be what you meant. I notice you said to try "-d myProject". What is myProject? I can only assume at the moment you mean myProject to be the CVSROOT definition, such as I have shown above.
CVS has a global -d option, which is what you used, and the checkout has a local -d option, which indicates the local target directory. If you try cvs - d :pserver:... co -d myProject aggregateproject, the checkout will create a myProject folder locally and checkout into it. We use the -d option when you perform a Checkout As.
Ah! Sorry, I foolishly overlooked that option. That'll teach me for thinking I knew all the options and not looking at the manual :| So, I tried your suggestion and you're dead right, using the -d option to checkout means that I get the directory structure: Class.java Class2.java stuff/Class.java UtilClass.java Exactly as when doing 'check out as'. With some googling, I've found that if I do: cvs co -N -d myProject aggregateproject I get this directory structure: myProject/javaproject/WEB-INF/src/com/mycomp/myproj/Class.java /com/mycomp/myproj/Class2.java /com/mycomp/myproj/stuff/Class.java /com/mycomp/util/UtilClass.java So perhaps the solution is to add the -N argument for the relevant "Check Out As..." options?
The use of -N is not really what you want as you woulsd want the result to be myProject/WEB-INF/src/com/mycomp/myproj/Class.java with the javaproject segment. We should probably disable Check As for alias modules.
Yes, I agree with your analysis, and what you suggest is the desired directory structure is absolutely right. But I'd certainly rather not have the functionality removed! It's precisely what my company needs as we have a code base that we need to take cuts across in order to extract discrete modules of work. We've worked out a plan for this using cvs modules, so obviously it would completely break our ability to work in one environment if we cannot use "Check Out As...". Judging by the cvs repository view, there is already code to recognise when a module is an alias type rather than one defined explicity by existence in the repository root directory. Wouldn't it make more sense to add an option in the "Check Out As..." wizard to allow users to override the top directory of their project (in my example case, "javaproject") with a user-defined value, which defaults to the name of the project they've chosen in Eclipse? Alternatively, I'd be perfectly happy to have a directory at the top level of the repository called WEB-INF, so that the -N option would work properly. I just feel there must be a relatively simple way around this problem. :)
The simple work around is to rename the project once it has been checked out. To redirect the checkout as you suggest, while possible, is not trivial as it requires modification to how the checkout works at the lowest level. Any alternatives for a solution to this will be cosidered, especially if they come in the form or a working and well tested patch;-)
(In reply to comment #7) > The simple work around is to rename the project once it has been checked out. > To redirect the checkout as you suggest, while possible, is not trivial as it > requires modification to how the checkout works at the lowest level. Any > alternatives for a solution to this will be cosidered, especially if they come > in the form or a working and well tested patch;-) I'm having the same problem as the original poster. I don't understand how renaming the project once it has been checked out helps? Renaming the project just gives the project a new name, but it won't create the necessary folders he needs: javaproject/WEB-INF/src/com/mycomp/myproj/
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
