> Ultimately it would be best to write up what you want to accomplish
> without referencing the CVS plugin. Describe the scenarios you want to
> support etc.. I can then probably tell you the problems you will need
to
> solve. Hopefully you are aware of Subversion's feature set and
> limitations as those will also have to be accounted for.
My general high-level goal is to allow a repository to be
structured in a way that's not constrained by (what appear to be)
artificial limitations imposed by subclipse. In other words: my build
scripts can checkout only the relevant parts of my repository, build
them, and tag (copy) them. So I'd like subclipse to be able to do the
same (or at least the first two).
Let me give a sketch of (a portion of) our repository layout so
that we can have a concrete example to work from (with some names
changed to protect the innocent):
trunk/
src/
Java/
[java code here]
build.xml
Images/
Foo/
[stuff we don't care about here]
ThirdParty/
[jar files here]
otherproj/
[more java code here]
otherproj-build.xml
The ant buildfile trunk/src/Java/build.xml references
"../../ThirdParty/*.jar" in its <classpath/> declaration and
"../Images/*.gif" in one of its <jar/> tasks. The build process I have
basically does:
svn co ${REPOS}/trunk/src/Java src/Java
svn co ${REPOS}/trunk/src/Images src/Images
svn co ${REPOS}/trunk/ThirdParty ThirdParty
cd src/Java
ant compile
So, the scenario I want to support: When one of our devs wants
to set up an eclipse project for this, he should be able to create a new
empty project, do the subclipse-equivalent of the three checkout
commands given above, and be off and running. (If those checkout
commands are creating a working copy that's not kosher from the
Subversion perspective, I'd like to know, because I certainly don't want
to bake something like that into our build process.)
What I want to avoid is forcing developers to check out all of
trunk/src/ as a single project -- or worse, forcing them to check out
all of trunk/ as a single project. The trunk/src/Foo/ and
trunk/otherproj/ directories are quite large (not to mention
irrelevant). I was discussing this on IRC yesterday with pombreda, and
he suggested using a separate project for each checkout. That doesn't
work because the relative paths in the ant build files will break. (Our
devs need to run ant within eclipse for things like annotations
processing and JavaCC grammars.)
Note that /trunk/otherproj/ shares some of the libs in
/trunk/ThirdParty/. So I don't think moving ThirdParty into /trunk/src/
is an option, either.
> In most cases, anything you can come up with should be solvable by
using
> svn:externals and a little willingness to be flexible.
I re-read the SVN book's section on externals, and it doesn't
sound like they're quite what I want. (The main issue being their lack
of sensitivity to being copied (i.e. tagged).) But I'd be happy to be
shown to be incorrect. :)
Thanks for your continued help,
Matt
Matt McHenry
412-690-2442 x150
Software Developer
Carnegie Learning, Inc.
Learning by Doing (r)
Helping over 375,000 students in 1,000 school districts succeed in math.
http://www.carnegielearning.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Tue Aug 8 18:08:10 2006