* Hyrum K. Wright <hyrum_at_hyrumwright.org> [091027 09:51] wrote:
> On Oct 27, 2009, at 4:35 PM, Daniel Widenfalk 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).
>
> We also just gave it a few minutes' discussion at the currently on-
> going Hackathon, and decided the short answer was "don't do that". It
> turns out that Subversion's handling of externals doesn't have very
> much information to detect this recursive relationship. Even worse,
> detecting a simple recursion might be easier, but detecting transitive
> recursion is Hard. So "don't do that." :)
While it is easier to say "don't do that", I was wondering about a
solution. Two came to mind.
1) UNIX typically gives an ELOOP error back to the client (VFS
consumer) when a max number of symbolic links are traversed in
the course of a lookup() operation.
2) track the externals in the client as they are traversed, if you
see the same external again, you have a cycle.
I suspect that the reason that UNIX does #1 and not #2 is for
two reasons:
1) it's cheaper
2) it would open you up to a race where someone continually
makes symlinks ahead of the kernel lookup routine.
--
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2415590
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-08 19:36:04 CET