David Corley wrote:
> I was thinking it could be possibly caught at commit time? Or am I
> missing something?
>
> On Tue, Oct 27, 2009 at 3:33 PM, Daniel Widenfalk
> <Daniel.Widenfalk_at_iar.se <mailto:Daniel.Widenfalk_at_iar.se>> wrote:
>
> David Corley wrote:
> > Hey all,
> > We've just implemented Subversion at our workplace, and after getting
> > everything running well together we ran into an odd problem last week.
> > One of our less experience team members inadvertently created an
> > svn:externals reference on a directory to a higher-level directory in
> > the same repository. This had the unfortunate effect of infinite
> > recursion on the directory, which in turn made updating difficult
> to say
> > the least.
> >
> > My multi-part question is:
> > 1. Does a subversion working copy contain the reference to the
> > repository where it was checked-out from?
> > 2. Assuming 1) is true, are there valid reasons why SVN would allow a
> > repo to have an svn:external reference to itself?
> > 3. Assuming 2) is false, is there a design case for some sort of check
> > on the svn:external property to ensure it doesn't reference the
> current
> > repository?
> >
> > WRT to 1), I'm guessing the alternative is that the SVN client rather
> > than the working copy retains the reference to the repo.
> > WRT to 3), There's only a major issue if the svn:external property
> > references a directory higher in the hierarchy than that which has the
> > svn:external property, which causes the infinite recursion.
> >
> > I'll welcome any comments on the issue.
> >
> > Regards,
> > Dave
>
> Hi all,
>
> I gave this a dime of my time and figured that you'd get a
> similar problem with two (or more) repositories that cross
> reference each other using svn:external. The only possible
> solution I can see would be for the client checkout code to
> handle this (if at all possible).
>
> Regards
> /Daniel Widenfalk
>
>
>
>
>
Yes, when committing a self referencing svn:external it should
be possible to use a pre-commit hook to validate that the
svn:external does not contain a path which is a direct ancestor
of the committed svn:external.

You still have the problem that external repositories can cross
reference in any manner and in any number of steps to get the
recursion. I.e. You'd have to traverse the entire destination of
an svn:external and look for svn:externals that may cause recursion
and that does not feel feasible.

I think that the only time that you can catch this is when "pulling"
in the svn:external and keep track of visited repositories/paths to
match for the recursion case.

Using a sparse checkout should allow you to correct your svn:external.