RE: [Subclipse-users] Identify subfolder of Eclipse project as working copy
From: Michael Schechter <mschechter_at_national.aaa.com>
Date: Thu, 18 Feb 2010 09:14:08 -0500
Nathan,
What we do here is slightly different, and is much less complex as only one IDE is in play. I'm hoping that this might give you some additional ideas on solving your problem, as I am not sure that what I'm proposing will work for you.
We have the following rough structure:
\product_tree
All of the above tree is in Subversion, except that everything under the "workspace" tree is on the ignore list, as is all IDE output (compiled classes, etc.). We use the Eclipse feature "File->Import->Existing Projects into Workspace", which leaves all the project content where it is (in an SVN-controlled directory), but accessible and modifiable from the IDE.
We also put the project-specific IDE metadata in Subversion. For Eclipse, that's .classpath, .project, and any custom builders (we have some code generated via Ant); I'm not sure what the corresponding file(s) would be for NetBeans. The workspace only contains the .metadata directory, not the actual source code.
This mechanism is based on a couple of IBM/Rational white papers on best practices for using WebSphere Studio Application Developer (derived from Eclipse) and Rational ClearCase in a multi-developer, multi-project environment.
I think this is extensible for your case, although you would have to have IDE-specific output directories at the project level to avoid stepping on compiled code and allow the use of multiple IDEs in parallel.
Hope this helps!
Michael Schechter
-----Original Message-----
I would like Subclipse to detect (or otherwise be told) that a subfolder of an Eclipse project is a working copy, when the Eclipse project itself is unversioned. That's the gist of it. If you're interested in knowing why, read on.
My research and experimentation has indicated that this is not currently possible. I have found little prior literature on the subject, including only a single thread from 2007 on this list that closely, but not exactly, matches what I am trying to do. If this *is* possible, or if a workaround is known, ignore my screed and please let me know.
I use multiple IDEs while working on the same project. I use a unique, non-overlapping directory for each IDE workspace so that I don't have to sift IDE-specific metadata. This means that the project subdirectory of one IDE is distinct from the corresponding project subdirectory of another IDE. I do not want each project subdirectory to be a separate working copy, because I don't want to commit an incomplete modification in the working copy of one IDE so that it is visible (after an update) in the working copy of another IDE.
I would thus prefer the working copy to be in a neutral location, merely referenced by the various project subdirectories of the IDE workspaces. Consider a layout like the following:
group-ID/
(Alternatively, I could create a symbolic link in each IDE project subdirectory for each child of "Working Copies/project", which would require me to do an "svn up" from the project root when mucking about in the working copy from a shell.)
With this configuration, I could make modifications while using one IDE and have the changes show up in another IDE (after a refresh) without an intermediate commit. Of course, I can set this up manually, but Subclipse does not recognize that "wc" is a version controlled directory, which means that I lose the convenience of performing commits and such from within the IDE.
The svn:externals property will not enable the above scenario, even if I was willing to create a mock repository for the IDE project, since intermediate commits would still be required.
I hope that what I would like to be able to do and why is clear. I understand that enabling Subclipse to accommodate this would require significant work and a rethinking of the way in which Subclipse interfaces with the Eclipse project model. If this is currently in the works, or if it is an item on a longer-term road map, great, I hope that a dev monitoring this list will chime in and let me know. What I am looking for from fellow Subclipse users is alternate, possibly radical recommendations for the interim.
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
This communication (including all attachments) is intended solely for
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
|
This is an archived mail posted to the Subclipse Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.