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.
Mounting CVS as version control file system does not allow to specify CVS module. Attempts to specify it as subdirectory of repository results in messages like "Corrupted CVS root" or "Unknown scrambling method". Using CVS check-out command directly from Versioning menu does allow to specify module but forcefully creates a subdirectory with the module name instead of placing files into specified working directory. 'Browse' button at CVS Repository path opens a file chooser for the local environment rather the one of pserver. My development machine is WinXP Pro but CVS is running on Solaris box and therefore is un-accessable via MS networks client. Proposed solution is to add CVS module field to the mounting wizard screen and allow mapping between modules and specified work directory without creating additional layers.
I've had similar problems when trying to create a new CVS module from within Netbeans. Whatever directory is specified as the Working directory, Netbeans insists on making its subdirectories separate repositories in CVS. This is annoying my co-workers! It should be possible to specify a working directory and import it directly as the parent directory for a new CVS module. Also, I have not found anyway to restructure directories without starting over again from scratch. E.g., on my first attempt I made the project directory for a new project the working directory in CVS. This creating multiple repositories like "src". I wanted to fix this by adding a parent directory, but found no other way to do that than to start all over again, creating a parent directory for the project as a new working directory and importing into a new CVS repository. Unfortunately, by the time I did that I had 4 inter-related projects. I created one parent directory above the 4 project directories and made this the working directory, but of course this produced 4 repositories in CVS, one for each project. I want everything in 1 repository. I have to introduce yet another parent above my projects root and rebuild everything to do that. The support in Netbeans should be better than this!
Except for the mounting bit this is equally relevant and irritating in NB 4.0.
The CVS integration allows you to specify the "working directory", that's the top-most folder into which a CVS repository (or a module from the repository) is checked out. You should not need to specify the "module" separately, you can set the working directory to be the just the directory where the module is checked out (but in this case some commands like import, checkout, export, rdiff, etc. will not work correctly), or use the Relative Mount Point instead. What specifically do you mean by "specify it as subdirectory of repository"? Can you please elaborate on how exactly do you have the CVS filesystem customized? When you checkou a module, checkout will create the directory with the name of the module by default. This is how cvs.exe behaves. In advanced mode, you can specify the -d option (Checkout Into Folder) to create a directory of a different name. Checkout of a module directly into the working directory does not seem to be possible. At least "cvs co -d . module" does not work on Windows. "Browse" button is already disabled in 4.0 builds when the "CVS Server Type" is not "local". Browse on a remote server is not possible. manawiz, I did not quite get what do you mean. The working directory should correspond to the root of the repository. The import, checkout, etc. should work O.K., import will create the same directory structure in the repository, as you have relative to the working directory. If the contextual import does not suit you (e.g. the the root of the working dir does not correspond to the root of the repository), Versioning -> CVS -> Global CVS Import can be used. There you can specify the directory in the repository where the local directory should be imported.
In both of my cases, I wanted to create new repositories in CVS. The first time I had a just a single project, and so set the working directory to the project directory. The second time I had 4 inter-related projects. The 4 project directories are all subdirectories of a Projects directory. I set the working directory to Projects. I could find to way to import the working directory. I tried Import from the contextual menu on the project directory in the first case, and on the Projects directory in the second case; i.e., in both cases this is the root node of the Versioning tab which shows the full path to the working directory. I don't remember exactly what happened, but in neither case did the import work. I was forced to import (again via the contextual menu) the subdirectories in each case. I.e., right now I have 4 separate repositories, one for each of my 4 projects, rather than what I wanted which is one Projects repository containing the 4 projects as subdirectories. So my core problem is that I cannot import the working directory, only its subdirectories.
Response to Mr. Entlicher You are right while judging by the look from the ivory tower. However, in the real world CVS modules are used for variety of purposes. One of them I mentioned in the mailing list prior to filing this issue: Our company is creating a version of the product customized for a particular client. Instead of branching the code and updating numerous build scripts (which would be a textbook usage of CVS), our CM and project management decided to save some time & money and created a module in CVS with copying all affected source tree there. This is how I got into that issue. What I want: 1. ability to be able to specify module name during CVS mounting 2. ability to map my source tree path with the CVS module. I.e. be able to check out from the module into my working directory if necessary. if "cvs co -d . module" does not work in windows, use "cvs co -d ..\myroot module" or something of that extent. I want from IDE the same functionality in regard of version control, that I am getting from WinCVS client. About the "Browse" button. If browsing is not available for anything other then "local" repository (which I doubt, because our IT rigged http agent where I can browse our remote repositories via IE or Mozilla), then "Browse" button should be disabled for any server value other then "local". I hope I clarified it enough.
Let me summarize the problems mentioned here: 1) Be able to check-out a module into specified working directory without creation a subdirectory with the module name. 2) 'Browse' button at CVS Repository path opens a file chooser for the local environment rather the one of pserver. 3) Be able to import specific directory(ies) to the repository at a desired folder. Anything else? The ability to be able to specify module name during CVS mounting - this was required because of 1) and 3) IMO. I do not think this is really necessary, because in CVS/Repository files there is the path to the appropriate repository. 2) Is fixed in 4.0. Browse is disabled for remote repositories. In general you can not browse on remote servers, the servers do not typically expose the content of their disk to the public. You have to know the connection settings. 1) This depends on the cvs client. Even WinCVS does not do that by default. When I do "Checkout Module" in WinCVS, it creates the module name in the working directory with the name of the module. When I check on "Override" and specify ".", it runs following command: cvs checkout -P -d . JavaApp1 This puts the content of JavaApp1 module into the working directory. However, cvs-1-11-17 or cvs-1-12-9 from cvshome.org do not work this way: cvs-1-12-9 co -d :pserver:xxx@xxx:/cvs . CVSROOT cvs-1-12-9 checkout: cannot open CVS/Entries for reading: No such file or directory cvs-1-12-9 [checkout aborted]: no repository When out built-in client is used for checkout, it creates the module folder anyway: cvs server: Updating ./CVSROOT U ./CVSROOT/checkoutlist U ./CVSROOT/commitinfo ... So, we need to explore how exactly WinCVS client handles "-d . ", what the server sends, etc. For the built-in client in might be fixable. 3) Versioning -> CVS -> Global CVS Import has "Repository Directory" field. Therefore it seems that we should perhaps remove the contextual Import and leave the global only? The contextual import creates the same structure that is locally in the working directory (so what you have relative to the working dircetory, will be relative to the repository root).
I think I'm finally understanding what is going on with #3. Being fairly new to CVS, I'm sorry if my report was a little confused. If I'm understanding correctly now, the Versioning Manager has mapped the working directory directly to the repository path. What I wanted to do was to create the working directory as a new subfolder of the repository path. I had hoped that the CVS Import item on the working directory context menu would do that, but it doesn't since the working directory is already mapped. Is that correct? Global CVS Import appears to require its own repository conneciton information. If that was used, would it create an entry in the Verisoning Manager automatically as a consequence of the action? This would be desired so I don't have to map it twice. Better for me would be if Global CVS Import could use existing Versioning Manager repository connection information. In general, what is the best way to create a new subdirectory of the main repository path as a new module mapped to a local directory of project directories? That is what I want to do. Right now I have the wrong mapping, with each individual project directory mapped to a top-level subdirectory of the repository root on the server. I want to restructure these into a Projects subfolder. Presumably that will require a new global import. It would be great if Netbeans supported some repository restructuring actions like this, but the most important thing is to be able to directly import.
I'd like to have 2 things from CVS client: a) be able to choose if I want to map the whole repository to my working directory or only a particular module; b) If I map repository to the working directory, I want to have a module name as a default for the directory it will create on the checkout, but to be able to overwrite it.
Since there are described hints to improve the current impl., changing to enhancement. The context CVS Import can have a field to specify the path in the repository (like global import). There is no place where "connections" are stored. In Versioning Manager the settings are connected with the individual working directories, and global import can not easily retrieve that info. We can perhaps introduce a storage of known "connections" independently on working directory. The working directory is mapped to the repository through CVS/Repository files. These contain the directory in repository from where the working directory comes. And this can be different for each individual directory. Therefore one module name is not enough. This binding is created by checkout and is followed by update, commit and other contextual commands. But not import, which ignores local CVS folders. From this point of view it has more sense to have import as a global command only. > What is the best way to create a new subdirectory of the main > repository path as a new module mapped to a local directory of > project directories? I would say to import the local files to the desired location in repository (via global import and specify "Repository Directory"), then checkout (via global checkout - use the advanced version of the dialog by holding CTRL - specify the "Working Directory" to the project directory, fill in "Repository Path" (relative to the repository root, probably the same that you specified for the import) and possibly also specify "Checkout Into Folder" (this is path relative to "Working Directory" into which the sources will be checked out, so you can put there e.g. "src"). Read the manual of cvs import and cvs checkout if you're in doubt. NetBeans do not support any repository restructuring actions, in general import and checkout can be used to do that. (Or move the folders directly in the repository.) To ggreenberg: a) be able to choose if I want to map the whole repository to my working directory or only a particular module; This is in fact done by checkout. CVS/Repository files do that mapping. Import does not read CVS/Repository files and therefore does not see these mappings. We should perhaps have the Import as the global command only. b) If I map repository to the working directory, I want to have a module name as a default for the directory it will create on the checkout, but to be able to overwrite it. In the global checkout, you can specify the "Checkout Into Folder" - path relative to "Working Directory".
Martin, is it really scheduled for 4.1? I'm affaid.
The Init, Import and Checkout commands are removed from the context menu. This prevents from misuse and makes the context menu shorter. Global commands are sufficient and more appropriate for that purpose. /shared/data/helm/cvs/repository/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/Bundle.properties,v <-- Bundle.properties new revision: 1.55; previous revision: 1.54 /shared/data/helm/cvs/repository/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvs.xml,v <-- cvs.xml new revision: 1.123; previous revision: 1.122
hmm...this doesn't seem to work for me as specified here. i see no way set up cvs so that all checked out projects can be siblings in one directory, no matter what its root is. i believe this is what manawiz was getting at with comment #1. if this is not the case, please close this issue and i'll add a RFE instead. the key here is that most people expect that all projects (or modules checked out in cvs) can be siblings in one directory. every other CVS system on the planet works this way, so netbeans needs to as well. as far as this issue is concerned, if i specify a working directory of 'f:\stuff\cvstest\mas' and a module named 'mas', netbeans should check out the module into 'f:\stuff\cvstest\mas'. instead, it checks it out into 'f:\stuff\cvstest\mas\mas'. am i wrong assuming that the working directory is the folder into which the module should be checked out?
Alvin surmised my issue correctly, so yes this is the same issue. According to Martin you should be able to do a Global Import. I do have all of my projects as siblings now but my issue was a little different as I was creating the modules, not importing existing modules from CVS.
Alvin, I still do not get it. 1) What prevents you from having all projects as siblings? I have all NetBeans projects as siblings. E.g. checkout "openide core java editor" from cvs.netbeans.org and you'll have them as siblings... 2) If I specify a working directory of 'f:\stuff\cvstest\mas' and a module named 'mas', netbeans should check out the module into 'f:\stuff\cvstest\mas'. Instead, it checks it out into 'f:\stuff\cvstest\mas\mas'. The current behavior is correct I believe, and consistent with the behavior of cvs.exe from cvshome.org. See https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_16.html#SEC123 Specifically: "The top-level directory created is always added to the directory where checkout is invoked, and usually has the same name as the specified module."
currently, the CVS implementation insists on having a 'working directory' (sic) as a parent to all vcs-controlled folders. since this working directory is different for each root, it is impossible to have projects as siblings to eachother if they come from separate repositories. in my case, i use a separate repository for home and two for work. with the current system, i am forced to use this directory structure: projects/netbeans/home/home_project_1 projects/netbeans/home/home_project_2 projects/netbeans/home/home_project_3 projects/netbeans/work_1/work_project_1 projects/netbeans/work_1/work_project_2 projects/netbeans/work_2/work_project_3 projects/netbeans/work_2/work_project_4 in this case the 'working directories' (sic) are 'home', 'work_1', and 'work_2'. this is very awkward. what virtually everyone wants is this structure: projects/netbeans/home_project_1 projects/netbeans/home_project_2 projects/netbeans/home_project_3 projects/netbeans/work_project_1 projects/netbeans/work_project_2 projects/netbeans/work_project_3 projects/netbeans/work_project_4 as far as the 'working directory' in the dialog is concerned, the section of the Cederqvist you refer to is absolutely correct. the problem is that one of us is using an incorrect definition of 'working directory', and it's not me. :P the working directory is NOT the directory where you run the checkout command from, but rather the directory that gets created/changed when you run the checkout. in the statement you quote: "The top-level directory created is always added to the directory where checkout is invoked, and usually has the same name as the specified module." the working directory is the "top-level directory" that's created, not the "directory where checkout is invoked". you're confusing the programmer's concept of a working directory with the CVS (or SVN) concept of a working directory. they're different. the Cederqvist doesn't really clarify this, but if you reread the Cederqvist from the beginning, the distinction is clear. this explains why the CVS module works the (strange and incorrect) way it does. if you want to make everyone very, very happy, download a copy of the excellent (windows software) Tortoise CVS (www.tortoisecvs.org) and play with it for a while. it should be a piece of cake to integrate the CVS commands into the Files/Favorites view in the same way that Tortoise CVS integrates into explorer. that would be perfect. you could do away completely with the Versioning Manager, the Versioning menu, the need for these parent directories, bizarre artifacts like those 'nbintdb' files (what DO those do?), and even the Versioning window. a much simpler, more intuitive interface.
Moving to CVSlite. We should revisit issues mentioned here for our new Checkout dialog.
I think Checkout wizard in new CVS module addresses this issue properly.