Bugzilla – Full Text Bug Listing
| Summary: | Allow Subversive to handle SVN working copy parts unrelated to the main project | ||
|---|---|---|---|
| Product: | [Technology] Subversive | Reporter: | Alexander Gurov <a.gurov> |
| Component: | Core | Assignee: | Igor Burilo <igor.burilo> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | mmuschol |
| Version: | 0.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Alexander Gurov
Discussion history (part 1): Hi, So, it's not what I thought about. As I understood your description, the actual SVN project was checked out by external tool and there is no direct relation between the SVN working copy and any project in the Eclipse IDE workspace. Subversive (as any other team provider) works by attaching its nature to the project. It means, if there are no attachment, then Subversive code won't be called at all. As far as I know, the only way to make it work at all is to attach "build-automoc" project to the SVN (in order to activate source control plug-in code for the project). After that next steps will be related to some corrections in Subversive. As I understand, the "build-automoc" project in your case shouldn't be shared through the source control, is it correct or not? If so, then the only way to do this is to allow Subversive to be connected to the project without its actual sharing. This is some non-trivial solution and for the moment I can't tell how much time it will take to implement it, as it will cause some serious changes in the most important parts of the Subversive plug-in code. If I'm wrong somewhere please correct me. Otherwise, if I understood your situation correctly, I'll create corresponding task on the tracker. Best regards, Alexander. 21.11.2011 22:29, Alexander Neundorf пишет: > Hi Alexander, > > On Monday 21 November 2011, Alexander Gurov wrote: >> Unfortunately I haven't worked with CDT at all, so there are some points >> I can't figure out, it seems. Let's check a few of different project >> layouts: >> >> 1) If we think in terms of typical Eclipse IDE workspace layout, it will >> be something like this: >> workspace >> workspace/project_1 >> workspace/project_1/src >> workspace/project_1/.project >> workpsace/project_2 >> workspace/project_1/src >> workspace/project_2/.project >> >> 2) Now if we add SVN into the equation we will get something like this: >> workspace >> workspace/project_1 >> workspace/project_1/.svn >> workspace/project_1/src >> workspace/project_1/src/.svn >> workspace/project_1/.project >> workpsace/project_2 >> workspace/project_2/.svn >> workspace/project_2/src >> workspace/project_2/src/.svn >> workspace/project_2/.project >> >> In other words each and every project is the separate SVN working copy >> itself. >> >> 3) If we use some specific tools like maven, for example, then it could >> be like this: >> workspace >> workspace/.svn >> workspace/project_1 >> workspace/project_1/.svn >> workspace/project_1/src >> workspace/project_1/src/.svn >> workspace/project_1/.project >> workpsace/project_2 >> workspace/project_2/.svn >> workspace/project_2/src >> workspace/project_2/src/.svn >> workspace/project_2/.project >> >> In this case every project is related to the same working copy with its >> root placed in the workspace. >> >> So, to sum it up, if I where to add actual processing of the linked >> nodes, I need them to be files or folders, that are placed somewhere >> inside the actual Eclipse project (project_1 or project_2 in my >> examples) or, in the worst case, inside the workspace root in the third >> case. Unfortunately I can't clearly see the whole actual structure of >> the SVN project in your example. > This is what I check out from svn, just one directory: > > $HOME/src/$ svn co http://svn.kde.org/.../automoc > > This gives: > > $HOME/src/automoc/ > $HOME/src/automoc/.svn/ > $HOME/src/automoc/CMakeLists.txt > $HOME/src/automoc/main.cpp > > > My Eclipse workspace is here: > $HOME/src/eclipse-workspace/ > but basically I don't do anything with it. > > > Then I create an out-of-source build-tree, where cmake will generate Makefiles > and the Eclipse project files for building automoc: > > $HOME/src/$ mkdir build-automoc > $HOME/src/$ cd build-automoc > $HOME/src/build-automoc$ cmake-gui ../automoc > > > This produces the build tree, containing Makefiles and the Eclipse project: > > $HOME/src/build-automoc/ > $HOME/src/build-automoc/.project > $HOME/src/build-automoc/.cproject > $HOME/src/build-automoc/Makefile > $HOME/src/build-automoc/CMakeCache.txt > > > In this directory I can run make, and it will build this project. > > Then I start Eclipse, and > * do "Import existing project" > * select $HOME/src/build-automoc/ for importing > * keep the checkbox "Copy into workspace" disabled, i.e. the files stay where > they are, outside my $HOME/src/eclipse-workspace/ > > > Then I have this project in Eclipse, and most things work fine. > Code completion, building targets, etc. > > In the generated .project file there is a linked resource pointing to the > original source checkout directory, i.e. to $HOME/src/automoc/. > > This is neither a subdirectory of the directory where the .project file is, > nor is it inside the Eclipse workspace, as shown above. > The problem is that the "Team" functions do not show up in that directory, > which is pointed to by the linked resource. > > >>> And a build tree for this source tree: >>> >>> src/automoc-build/ >>> src/automoc-build/.project >>> src/automoc-build/.cproject >>> src/automoc-build/Makefile >>> src/automoc-build/CMakeCache.txt >>> src/automoc-build/main.o >>> src/automoc-build/automoc >> So, I'll really appreciate it if you >> could please provide me with an example of resource tree, starting from >> the root of SVN working copy (where the top .svn folder is placed) and >> point where the .project file is placed and to where it is linked. >> Probably the best way to see it will be a sample project. If that is the >> case, then we also have two options: >> 1) You could send me a sample of a CDT project > The .cproject file probably/maybe does not even matter as far as I understand. > I attached one, the important part is the "[Source directory]" linked > resource. > >> 2) You could teach me where I should get right CDT version and how to >> create and configure the project, so I'll reproduce the situation by >> myself. > I'll prepare a sample project and send you later. > > > Would it work if I would create actual symbolic links in disk to the source > directory ? > I'll try (...but it would not be ideal, since it wouldn't work under Windows). > > Thanks > Alex > > > _______________________________________________ > subversive-dev mailing list > subversive-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/subversive-dev _______________________________________________ subversive-dev mailing list subversive-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/subversive-dev Discussion history (part 2): Hi Alex, 22.11.2011 18:44, Alexander Neundorf пишет: > On Tuesday 22 November 2011, Alexander Gurov wrote: >> Hi, >> >> So, it's not what I thought about. As I understood your description, the >> actual SVN project was checked out by external tool > Yes. > >> and there is no direct relation between the SVN working copy and any project >> in the Eclipse IDE workspace. > Only the linked resources. > But I could put any necessary tags into the .project file or e.g. also a > .subversive file. Unfortunately it won't help at all. > >> Subversive (as any other team provider) works by attaching its nature to >> the project. > I'm no Eclipse expert. Can you please explain what this means ? > What means attaching ? Can I influence this ? What does "nature" mean here ? Attaching project to the source control provider nature is an action that could be done like this (line from the Subversive code): RepositoryProvider.map(project, SVNTeamPlugin.NATURE_ID); That line means that for the project defined by the variable "project" in an appropriate moments of time will be called code of plug-in that has the same nature as specified by the second parameter (string constant). The "attached nature" setting is the persistent one, so it is stored somewhere inside workspace's ".metadata" folder. You can influence it the same way (just that you'll need to do some calls to the Eclipse Team API), but it won't work in the end because sharing the project is not the same as just attaching source control provider nature to it. It is expected that the shared project should be related to some repository (SVN repository in this exact case) and should contain source control metainformation inside the project root folder. So, I'll open the task related to this discussion on the Subversive tracker, but I can't even tell you any expectations regarding when it could be done, since it requires great amount of efforts to be applied in both of the Subversive parts: core an UI. > >> It means, if there are no attachment, then Subversive code >> won't be called at all. >> >> As far as I know, the only way to make it work at all is to attach >> "build-automoc" project to the SVN (in order to activate source control >> plug-in code for the project). > How would I "attach a directoy to SVN" ? > >> After that next steps will be related to >> some corrections in Subversive. As I understand, the "build-automoc" >> project in your case shouldn't be shared through the source control, is >> it correct or not? > > Yes, the build directory is not in source control. > One developer can chose to create Eclipse projects, another one can choose to > generate XCode projects, Windows developers may generate VisualStudio > projects, others will only generate Makefiles. > All this is completely up to the respective developer, and build trees are > "volatile" in that sense. > >> If so, then the only way to do this is to allow Subversive to be >> connected to the project without its actual sharing. This is some > Would it help if I create an actual symbolic link in the file system which > points from build-automoc/ to automoc/ ? > > e.g. > $HOME/src/build-automoc/SymlinkToSrcDir > which points to > $HOME/src/automoc/ > > This would make it work at least for any UNIX, if it would help. > >> non-trivial solution and for the moment I can't tell how much time it >> will take to implement it, as it will cause some serious changes in the >> most important parts of the Subversive plug-in code. >> >> If I'm wrong somewhere please correct me. Otherwise, if I understood >> your situation correctly, I'll create corresponding task on the tracker. > I think you are right. > > Alex > _______________________________________________ > subversive-dev mailing list > subversive-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/subversive-dev *** Bug 323019 has been marked as a duplicate of this bug. *** This issue has been migrated to https://gitlab.eclipse.org/eclipse/subversive/subversive/-/issues/91. |