[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 1024 - trunk/subversion/libsvn_client trunk/subversion/tests/clients/cmdline

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-01-23 16:35:39 CET

Greg Stein <gstein@lyra.org> writes:

> On Tue, Jan 22, 2002 at 07:54:53PM -0600, philip@tigris.org wrote:
> >...
> > * subversion/libsvn_client/ra.c
> > (svn_client__open_ra_session): Add new arbitrary_wc parameter, which is
> > set when the working copy revision does not necessarily relate to the
> > revision coming from the server.
>
> Gah... why a new parameter? If you are not referring to the revision in the
> working copy, then you must ignore everything in the wc. Stuff coming from
> the server (deltas, diffs, prop deltas, etc) are all going to be relative to
> the false revision and cannot be applied to the wc. Thus, the wc is
> irrelevant.
>
> And we already have a way to express that: base_dir == NULL. I suspect the
> "arbitrary_wc" flag is wrong. Use NULL for base_dir instead.
>
> -1 on this change pending discussion/explanation here.

OK, I'll revert it. I think the problem is that when this
get_wc_prop() stuff was introduced it broke the 'svn diff -rREV'
editor. I didn't understand why it was broken, or even that it was
broken initially, so I used the method for 'svn diff -rREV1:REV2'.

However as far as I can see the fix for 'svn diff -rREV' is to pass a
null base_dir as the wc does not in general match the requested
revision (this certainly fixes the failing tests). Then it is natural
for 'svn diff -rREV1:REV2' to pass a null base_dir as well.

I think a more sophisticated fix would involve a new get_wc_prop()
callback for diff that would return props from the current wc where
appropriate, and null otherwise. This get_wc_prop() function would
need to operate in tandem with the editor to determine whether the
file in question was part of the wc or not. This would then allow
'svn diff -rREV' to send deltas where possible.

-- 
Philip
---------------------------------------------------------------------
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:58 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.