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

Re: svn commit: r935095 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/diff.c libsvn_client/prop_commands.c libsvn_client/revisions.c libsvn_wc/node.c

From: Daniel Näslund <daniel_at_longitudo.com>
Date: Thu, 22 Apr 2010 07:53:02 +0200

On Thu, Apr 22, 2010 at 01:28:11AM +0200, Neels J Hofmeyr wrote:
> Daniel Näslund wrote:
> > On Fri, Apr 16, 2010 at 11:09:06PM -0000, neels_at_apache.org wrote:
> >> ==============================================================================
> >> --- subversion/trunk/subversion/libsvn_wc/node.c (original)
> >> +++ subversion/trunk/subversion/libsvn_wc/node.c Fri Apr 16 23:09:06 2010
> >> @@ -626,6 +626,75 @@ svn_wc__node_get_base_rev(svn_revnum_t *

[...]

> >> + else if (status == svn_wc__db_status_deleted)
> >> + {
> >> + /* This node is deleted, but we didn't get a revnum above. So this must
> >> + be a delete inside a locally copied tree. Return the revision number
> >> + of the parent of the delete, presumably the copy-from revision.
> >> + ### This is legacy behaviour, and it sucks. */
> >
> > I thought that we would only get a rev from read_info() when we have a
> > delete if the op_root was the path itself, e.g. that we would need to
> > scan upwards if we had deleted A/D and was checking the rev of A/D/G/pi.
>
> My code was wrong. I fixed that in above-mentioned revision. Thanks!
> Not sure if read_info() even returns the revision for the op_root. I think
> it did otherwise during my recent testing.

Yeah, read_info() gives us SVN_INVALID_REVNUM if there is a WORKING node. For a
plain delete op_root (e.g. base_del_abspath) we have a WORKING node and should
use base_get_info(). For some reason I had a strange idea of the op_root
not beeing a WORKING node. That was _wrong_.

Daniel
Received on 2010-04-22 07:54:34 CEST

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