You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Corley <da...@gmail.com> on 2009/10/27 15:20:48 UTC
Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411698
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by Alfred Perlstein <br...@mu.org>.
* 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].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
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." :)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411704
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by Nick Stolwijk <ni...@gmail.com>.
Forbidding it is difficult, not to say impossible. Just revert the specific
commit or do a remote propget / remove line / propset.
With regards,
Nick Stolwijk
~Java Developer~
IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl
On Tue, Oct 27, 2009 at 4:35 PM, Daniel Widenfalk
<Da...@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
>
> P.s. Dave, I'm sorry for the double posting.
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411702
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411705
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by Daniel Widenfalk <Da...@iar.se>.
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
P.s. Dave, I'm sorry for the double posting.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411702
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by Mike Dixon <mi...@denovosoftware.com>.
David Corley wrote:
> 2. Assuming 1) is true, are there valid reasons why SVN would allow a
> repo to have an svn:external reference to itself?
Certainly. The svn:externals syntax even includes a shorthand for "this
repository"; use ^ in place of /path/to/repo.
For example, laying out your repo like this:
/
/libs
/libs/lib1
/libs/lib2
/projects
/projects/project1/
/projects/project1/libs
Then you set svn:externals on /projects/project1/libs to
^/libs/lib1 lib1
^/libs/lib2 lib2
This allows you to have multiple projects that use shared libraries,
while avoiding having the library code duplicated inside each project.
Of course, you have to be careful when setting it up, as it can lead to
the recursive situation you ran in to.
-Mike
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411737
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by Daniel Widenfalk <Da...@iar.se>.
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@iar.se <ma...@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.
Regards
/Daniel Widenfalk
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411708
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Not a bug, but a subversion design issue that perhaps needs
addressing......comments please
Posted by David Corley <da...@gmail.com>.
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
<Da...@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
>
>
>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411703
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].