[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: HP-UX failures

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-04-19 20:48:30 CEST

Mark Benedetto King wrote:

>On Fri, Apr 19, 2002 at 07:53:38PM +0200, Branko ?ibej wrote:
>
>>Yes, that's what I'm counting on. :-)
>>However, I think we it'll turn out that having is list of open
>>repositories would be a good thing in the long run, anyway (think
>>cross-repository copies).
>>
>
>Can we manage to shoot ourselves in the foot through aliasing?
>
>i.e., are "file://foo/bar/baz" and "file://foo/bar/../bar/baz"
>going to be recognized as "different" and thus cause trouble
>when we open the same repository a second time?
>
I don't think this is a valid URL. Even if it is, I don't propose
relying _only_ on the cache -- we'd have to do what split_URL does now
for the firs repo we open, anyway.

>If ".." seems to be a pathological case, what about symlinks?
>
>Or do people who manage to break things this way deserve
>what they get?
>
Well, right now svn won't work for them, because we don't do
cross-repository operations. When we do, everythong should work fine,
except that it'll be less efficient.

And I totally agree with Mike.

You know, you have the same potential problem with http:// URLs, too,
and there's absolutely nothing you can do about it -- unless you
introduce a repository GUID and check that. Not to mention that
different paths can have different access restrictions.

But I'm not about to lose sleep because of that. I've long since found
that users can always find a way to screw up you hadn't thought about,
so I just live with that. :-)

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 19 20:49:26 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.