On 10/19/07, David Glasser <glasser@davidglasser.net> wrote:
> On 10/19/07, Philip Martin <philip@codematters.co.uk> wrote:
> > "David Glasser" <glasser@davidglasser.net> writes:
> >
> > > On 10/19/07, Philip Martin <philip@codematters.co.uk> wrote:
> > >> "Ben Collins-Sussman" <sussman@red-bean.com> writes:
> > >>
> > >> > The question is: why the wc-searching routine
> > >> > (update_editor.c:locate_copyfrom()) think that it's found the correct
> > >> > version of the file, when it's not? Answer: it seems to be getting
> > >> > stale svn_wc_entry_t information. It's reading a couple of entries
> > >> > files from disk, rather than from a more recent adm_access set still
> > >> > held in memory, and getting an incorrect (stale) last-changed-rev
> > >> > value. From poking around in gdb, it seems that the entry_t's which
> > >> > are write-cached in memory are correct -- they have the proper
> > >> > last-changed-rev values, but simply aren't flushed to disk yet.
> > >> >
> > >> > I attempted to solve this by passing in the edit_baton->access_set to
> > >> > the searching routine, but it's not fixing the problem. I've attached
> > >> > my patch-in-progress below. Can we get some more eyes on this
> > >> > problem?
> > >>
> > >> I think there are two bugs here. I believe it is wrong for
> > >> locate_copyfrom to use a read-only snapshot of the working copy, your
> > >> patch to pass an access baton looks like the right thing to do,
> > >> although I think that the _try calls should take write locks. However
> > >> that's not what is causing the current failure.
> > >
> > > Why is that? It sounds like a read-only operation...
> >
> > Without a write lock some other Subversion process could change or
> > delete the file in the interval between the decision to use a file and
> > the moment it gets used.
>
> Huh. When is it ever safe to not take the write lock, then?
I must admit I was wondering the same thing...
-garrett
---------------------------------------------------------------------
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:03:39 2007