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

Re: Right place for cleaning up entries fields on delete

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-09-22 23:50:21 CEST

Erik Huelsmann <ehuels@gmail.com> writes:

> On 9/22/05, Philip Martin <philip@codematters.co.uk> wrote:
>> There are already a number of places where the wc code is not atomic
>> and probably should be. I think this might be adding another.
> Ok. I think you are saying this should all be loggy operations, right?

Yes, it's something to worry about.

I've been trying to remember what makes me think this is a problem,
and as far as I can recall the handling of deleted=true in
svn_wc_revert2 is a bit dodgy: we remove an entry and then put back a
deleted=true. The whole wc code is so horrible these days it's hard
to get a handle on it, if svn_wc_revert2 has to put back deleted=true
why doesn't it be do the same with missing=true?

> Do you consider it a task of wc-replacements to get this right, or is
> that a separate issue to you? (which would -of course- include fixing
> the other ones too)

wc-replacements doesn't have to fix any of the existing atomic
problems, such changes probably belong on some other branch or the
trunk. Ideally no new atomic problems would be introduced, but
wc-replacements doesn't need to meet higher standards than the
existing code on the trunk.

> BTW: which part of the 'remove copyfrom-url and copyfrom-rev' do you
> consider non-atomic? Modifying an entry is done with 1 call into
> svn_wc__modify_entry.

I don't know whether Ivan's change would have introduced an atomic
problem, it's quite possible his change will be been OK. If he thinks
svn_wc_delete2 is the best place to do then he may be right.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 22 23:51:14 2005

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