You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alfred Perlstein <br...@mu.org> on 2009/11/08 18:14:35 UTC

Re: Not a bug, but a subversion design issue that perhaps needs addressing......comments please

* Hyrum K. Wright <hy...@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@subversion.tigris.org].