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

Re: Nasty double-replace copy-on-update bug

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-10-19 17:52:55 CEST

On 10/19/07, Philip Martin <philip@codematters.co.uk> wrote:

> If I quit out of gdb after running the first log, and then run cleanup
> I get:
>
> $ svn st -uv wc
> * wc/aardvark
> 3 1 pm wc/alpha
> ! * 3 ? ? wc
> Status against revision: 3
> $ cat wc/alpha
> This is the file 'g123'.
> $ cat wc/.svn/text-base/alpha.svn-base
> This is the file 'g123'.
>
> Notice that alpha is showen as up-to-date despite having
> committed-rev=1 and the wrong working text and text-base. That's the
> sort of thing the log files are supposed to prevent. I can't run
> update, because of the bug, but even if I could how would the client
> know to update alpha?

Argh! I'm trying to see if I understand the situation here: because
we're writing & executing a log "early", we're writing an out-of-date
committed-rev value to .svn/entries? Whereas if we had allowed the
log to be written and executed at normal close_directory() time, the
log would have included the correct information?

I think I'm confused... at what point is the correct data ever written
to the loggy?

> > The props in memory are then applied to the file-baton. The
> > difference, though, is that the first blocks just loads up typical
> > user-created properties, while svn_ra_get_file() returns *all* props:
> > normal user props, but also "weird" live properties like the
> > svn:wc:entry:* props that get cached in .svn/entries. (This is
> > perfectly fine; close_file() knows how to filter these different
> > types of props.)
> >
> > So in the case of an svn_ra_get_file() fetch, the
> > svn:wc:entry:last-committed-rev property is definitely being fetched
> > and pushed into the file-baton. But when we're copying an existing
> > file's properties over, we're not dup'ing the last-committed-rev prop
> > at all.
>
> In this case alpha is created by doing svn_ra_get_file(gamma@1) and
> copying committed-rev=1. The log file that creates alpha sets
> committed-rev=1. I don't see how that can be anything other than a
> bug.

Huh? The whole bug here is that alpha isn't fetched via RA, it's
being copied from an existing wc file.

Let me walk over update-test #40 again; I think I don't understand
where you've gdb'd.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 17:53:08 2007

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