Re: SVN externals handling

Kohsuke Kawaguchi wrote:
> Renaud Bruyeron wrote:
> > I have an issue with a couple of projects that use svn:externals.
> > The use-case looks like this:
> > Project A
> > - build.xml
> > - src
> > - project B (via external)
> > -- build.xml
> > -- src
> > - project C (via external, requires B.jar)
> > -- build.xml
> > -- src
> >
> >
> > If project B or project C are modified, project A should rebuild. 
> > However the SCM trigger does not know anything about externals 
> > because svn info does not recurse into externals.
> > Another approach would be to have 3 projects in Hudson and cascade 
> > the dependencies.
> > However, project B or C cannot build on their own, therefore the 2 
> > projects would only be simple checkouts and act as external triggers 
> > for project C...
> > Moreover, project B or C could be multi-gigabyte folders that are 
> > already checked out by project A's external setup, leading to a lot 
> > of wasted space.
>
> Ah, this is interesting. I guess it works, except the waste you 
> mentioned, and the branch issue.
Yes I've tried this here with a large project and it works quite well. 2 
drawbacks:
* double the size of the checkout (I go from 1GB to 2GB in my case...)
* hudson is not really aware of the externals and only calculates 
"changes" for the root project.
> > I looked into the subversion SCM provider, and it could support 
> > externals natively by changing a few things (it looks like a bit of 
> > work though):
> > * after svn checkout or svn update, run svn status --xml to pick up 
> > the locations of the externals
>
> Does "svn status -xml" work recursively? Or will Hudson need to run 
> this for each sub-directory?
Yes it recurses to find all the modified stuff. For a fresh checkout, it 
will not display anything except the externals:
<entry
  path="A/B/C">
<wc-status
  props="none"
  item="external">
</wc-status>
</entry>

This means that folder C in A/B is actually an external. Then svn info 
--xml on A/B/C gives us the actual SVN url.
> > * if (externalSupportEnabled), run svn info --xml on the root AND on 
> > the externals location
> > * somehow merge change info from the different externals
>
> Once we know where svn:externals are, I think the rest is probably not 
> too hard. SubversionSCM class already supports multiple modules, so in 
> a way this is just a slight variation to that.
ah yes I see - could we simply "register" the externals as "modules" so 
that we get automagic changeset merging?

I guess it is less daunting than I initially thought. My hack with 
cascading projects kinda works for now, but I sure would like to see 
this improvement.


- Renaud