I use and like svn:externals as well. However, it does have a flaw in
that it doesn't work well with tagging or branching. Often you "tag"
in order to mark a snapshot in history. However, the svn:external
symlink will likely still point at the trunk, so it doesn't really
take a snapshot of that. I think if you use it properly (i.e. linking
to a branch or tag in an external project), that works best.
Matt
On 11/30/07, Dean Hallman <[EMAIL PROTECTED]> wrote:
> 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]
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
