[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] RE: Implementing "check out into existing project"

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-08-08 18:22:02 CEST

"McHenry, Matt" <mmchenry@carnegielearning.com> wrote on 08/08/2006
12:07:58 PM:

> 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

> 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. :)

svn:externals could solve this problem and it would not be as prone to the
problems you describe because you would really be tagging "trunk".

You could create a new folder in your repository. Call it "Eclipse
Projects" or "IDE Projects" if you want to support multiple IDE's. Then
store an empty pre-configured Eclipse Java project in this location. This
project would have this property set on its root:

svn:externals ThirdParty url://server/repos/trunk/ThirdParty

The project would have a src folder, and that folder would have this

svn:externals Java url://server/repos/trunk/src/Java
                Images url://server/repos/trunk/src/Images

Then your Eclipse developers just need to checkout this project and it
will grab what they need automatically, and it will also be configured
correctly for them.

What you are doing via Ant is fine, except if you wanted to do anything
like a commit, or create a tag from the working copy you would be a little
bit handicapped because your process has created 3 stand-alone working
copies. So you cannot perform any Subversion operation that operates on
all 3 of them. Subclipse would currently have the same problem.

Finally, if you wanted to implement that in Subclipse the hardest part is
going to be the local actions. You could not select the Project root or
src folder and do Team -> Commit/Synch/Update/ anything because that
folder is not a working copy. So you'd have to root out all code that
might make these assumptions and fix them. The actual checkout part would
not be too difficult, you would just need do the right validations and the
UI changes.


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:22:44 2006

This is an archived mail posted to the Subclipse Dev mailing list.