Matt,
Sure, I'll give some more details.
I'm actually still working out some of the details for AppFuse
specifically. But I use this technique all the time in my Java, Eclipse
projects. I found it helps to keep my Java source code separate from my
Eclipse workspaces, while still enabling you to check in and share my
Eclipse workspaces with others. This allows you to have a src directory
with Java sources only and a separate workspaces directory with Eclipse (or
IDEA, NetBeans) projects that point to the sources they should include. So,
you can have the same source module imported into multiple concurrent
Eclipse, NetBeans, IDEA projects. And checkins from any of those projects,
commit to the same places.
What makes this work is subversion's "svn:externals" property. I think
svn:externals is a kind of hidden gem in Subversion. It's essentially
Subversion's equivalent to a Unix soft link ("ln -s"). With svn:externals,
you can have one real copy of a directory, and expose it over and over again
at multiple, distinct paths in the subversion repository. Within
subversion's repository, it is just a link, so there is no code
duplication. However, when you check out locally, the linked resource is
checked out anew at each linked path.
All the main subversion clients support svn:externals, but from the command
line, you can add an external link as follows:
c:> cd helloworld-prj
c:> svn propset "svn:externals" "src svn://myrepo/trunk/hello/src"
This sets a local "src" directory to point to "svn://myrepo....."
(Note, svn:externals only works with directories, not files)
c:> svn commit .
c:> svn update
.... starts downloading linked resource inplace
Now, the helloworld-prj/ directory has a child directory named "src" that is
a link to "svn://myrepo/trunk/hello/src". Note, you can even link to
directories in different svn repositories, stored anywhere. Any valid svn
url will do.
So, back to how I'm using this with AppFuse. With the previous background,
it's simple really. I'm just building an AppFuse modular-archetype
workspace for Eclipse with everything I need it in to make it Tomcat
deployable. Once, I have this workspace fleshed out, I check it into a
separate workspaces location in subversion, so my AppFuse workspace is
sharable with other team members. Then, at the right directories where my
code should be linked in, I add an svn:externals to import my code at
exactly the paths needed in the workspace. Now, I have workspace and
AppFuse code in one separate repository (or path in the same repository),
and my code in a different location. But they are merged together by a
simple "svn update". I can have 2 or more AppFuse workspaces, one
collapsed, one appfuse:full-source and one "war:inplace" all linking to the
same application-specific sources. And commits travel back to the svn
location from which they originated.
Upgrading is easier because you only have to work with the checked in
AppFuse workspace to accomplish the upgrade, leaving your app-specific code
out of it completely. You could either check in a new, version specific
workspace, or merge the AppFuse changes in with "svn merge" if you have
modifications to AppFuse you want to retain through the upgrade.
Hopefully, sufficient detail. Let me know if anything is still unclear,
and I'll elaborate.
Dean
On Nov 30, 2007 10:19 AM, Matt Raible <[EMAIL PROTECTED]> wrote:
> Dean,
>
> Can you provide some more details on how you're doing this? There's
> some folks on this list that are new to SVN.
>
> Thanks,
>
> Matt
>
> On Nov 30, 2007, at 1:16 AM, Dean Hallman wrote:
>
> > I'm just getting started with AppFuse, so this might be old news...
> > But I wanted to suggest a technique for structuring your AppFuse-
> > based projects (for those using subversion anyway).
> >
> > IMO, ideally you may want to work in an appfuse:full-source (or
> > war:inplace) expanded view of your project, but that puts your code
> > and appfuse code together - which isn't ideal for version control
> > and upgrading. Furthermore, it is somewhat difficult to switch
> > between a collapsed appfuse project and an expanded one for serious
> > debugging. Svn:externals is a really good solution for a situation
> > like this. I'm using AppFuse with svn:externals to create a full
> > source project, with my code brought in via an svn:external
> > reference. This way, I can drop my code into multiple concurrent
> > versions of AppFuse without problem, since it is just a pointer out
> > to my code and subversion overlays the two for me automatically.
> > This clearly separates my code from appfuse code and when I check
> > in, the files know which subversion repository or path to commit to.
> >
> > Anyway, I've found this a useful technique applied to AppFuse-based
> > projects, so I thought I'd pass it along...
> >
> > Dean
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
