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

Re: svn commit: rev 617 - trunk/notes

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-12-10 04:09:57 CET

On Sun, Dec 09, 2001 at 09:28:11PM -0500, Greg Hudson wrote:
> On Sun, 2001-12-09 at 21:14, Greg Stein wrote:
> > To reach the baseline collection for rev=595, it must ask for a properly
> > from the /trunk/STACK resource. That resource does not exist in the HEAD, so
> > it doesn't exist, so you can't ask for the property.
>
> It seems like we are Doing Something Wrong here, by asking for a
> property from the head when we aren't doing anything related to the
> head.

It is "somewhat wrong" but the Right answer is (as always) a bit more
complicated :-) (and I'm not sure yet what the Best Right Answer is)

> I would say, for now, that when we aren't grabbing the baseline
> revision, we should start at the root and go from there. I don't have a

At the moment, we don't know the "root". We may need to publish that at some
point, but we don't have it.

> good enough handle on how we're using DAV to know what level of
> inefficiency this introduces, but I expect it's not important. If it
> does turn out to be important, we could try the full path as an
> optimization and then fall back to starting at / if that fails.

Efficiencies probably don't matter much since these would be infrequent.

More on what to do later...

> (Though, I'm concerned about that. /foo/bar in the head could refer to
> a totally different directory than /foo/bar in some earlier rev. Will
> everything still work if this is the case?)

We're composing URL paths rather than FS nodes, so yes: it will work.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:52 2006

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.