Re: [PROPOSAL] Dealing with large directories/difficult to organize trees.

On Mon, Jul 11, 2005 at 09:57:27PM -0400, Greg Hudson wrote:
> Yes, there is a special case. Without the special case, "svn update
> foo" would fail because there is no wc entry for foo.
>
> You don't have to understand this in terms of non-recursive checkouts.
> Go into /trunk/subversion/notes and update to r15000. Now try "svn
> update propmerging_sanity.txt". It works! Now update back to r15000
> and try "svn cat propmerging_sanity.txt" and "svn cat
> propmerging_sanity@HEAD". It doesn't work, because "svn cat" doesn't
> have the special case.

Per our conversation on IRC the above isn't really accurate. There is
no special case code to make update in a non-recursive diretory work.
It is a consequence of the fact that update only uses a single URL, the
anchor of the wc. When calling svn update propmerging_sanity.txt the
anchor is the URL to the notes directory. The resulting reporter system
then uses relative paths to that URL. Thus the reason the update works.

cat fails in this case because cat needs to have the specific URL to the
file to use with svn_ra_get_file(). It would be possible to take the
anchor path and construct the URL and ignore if the entry doesn't exist
for cat and make what you're describing above but that would be a
special case to cat because cat uses a single URL to the single file.

> I wasn't arguing against "svn include" on the basis of changing the
> interface; I was arguing against it on the basis that the functionality
> is natural to "svn update", so we don't need a separate command.

More so than I realized since it already works and works mostly by as a
consequence of our architecture rather than by design. So I have to
agree with you.

> > Yeah but we don't really have a way to know what the server supports.
>
> In ra_svn, we certainly do: capability negotiation at connect time.
>
> In ra_dav, the situation might be a little more complicated because we
> don't get data from the server before sending the custom report
> containing the wc state, I believe. But I think there are ways; I
> believe we generally make some kind of request before launching into the
> custom update report, and we can get back a header on that request.

Yeah sorry, I should have said I was specifically talking about dav.
The svn situation is much simpler because of the stateful protocol.

We do talk to the server before the REPORT request by doing a PROPFIND
request to find the proper URL to use for running the REPORT. There is
a header the server can return with that to communicate something like
capabilities. Problem is we're not technically required to do that
PROPFIND before the REPORT and the server isn't technically required to
provide that header.

In this particular case I believe we always do a PROPFIND before the
REPORT. So we could probably start emitting a header to say that we
support limited updates. But I need to do a trace on the code to see
why we're doing the PROPFIND it's not 100% clear to me right now where
that PROPFIND request is coming from when looking through the update
code. It's probably some call to get_latest_revnum(), which makes it
not terribly useful for this situation.

But your limit_path() trick does appear to work, here's an example:

$ svn co -N http://svn.collab.net/repos/svn/trunk
[output clipped]
$ cd trunk
$ svn up notes
[output clipped]
$ svn switch http://svn.collab.net/repos/svn/branches/1.2.x/notes notes
[output clipped]
$ svn up | grep notes
[no output]

So notes was just skipped.

But is this really an acceptable way of getting an update to skip over a
path? If so we can make this work without a server change.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org