On Mon, 2005-07-11 at 12:57 -0700, Ben Reser wrote:
> > You can already do the equivalent of "svn include" with "svn update".
> > (Incidentally, that's done as a special case in svn_client_update which
> > could also benefit other commands. For instance, "svn cat foo@375"
> > doesn't work if foo doesn't exist in the wc, but it could if we used the
> > parent directory's URL to identify what foo is supposed to be.)
>
> Hmm I don't think really a special case.
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.
> I'm generally under the impression that people don't use non-recurssive
> checkouts becuase they don't work right.
People do use non-recursive checkouts. They work as long as you never
recursively update the non-recursively-checked-out directories. (You
have to manually update the children you care about.) But this is a mot
point.
> Given that I think we probably
> should feel free to change the interface without worrying too much about
> breaking anyone. If they're using it, it's already broken anyway.
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.
> > As I mentioned on IRC, I think there may be ways to abuse link_path to
> > accomplish this. It's not the best option in the steady state, but as a
> > compatibility hack it's probably better than receiving and ignoring a
> > huge swath of updates.
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 12 03:59:00 2005