> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: donderdag 18 februari 2010 11:07
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org; philip_at_apache.org
> Subject: Re: svn commit: r909093 - in
> /subversion/trunk/subversion/libsvn_wc: adm_ops.c workqueue.c
> workqueue.h
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> > This type of changes should be handled outside the WQ operation.
> >
> > All workqueue operations must be able to cope with restarting multiple
> times.
> >
> > This operation can delete the entry from the local_abspath. (One of
> > the tiny details in fold_scheduling :( )
> >
> > In that case you can get yourself a workqueue item that can never
> > complete, because it can't find the entry.
>
> In my defence I think I just moved that bug from the previous loggy
> code :)
>
> >
> > The model for this kind of operations we defined to handle this was:
> > * Open SqLite Transaction
> > * Perform database updates
> > * Insert WQ operation(s)
> > * Commit Transaction.
> > * Run WQ operation.
> >
> > This way you always have a consistent database.
>
> OK.
>
> >
> > I'm running tests on a change that moves all entry scheduling
> > changes to svn_wc_schedule_delete to a single
> > svn_wc__db_temp_op_delete() operation. (The reason that it is a
> > temp_op and not the normal op is that it isn't recursive)
> >
> > It is starting to look like my helper function handles the current
> > corner cases.
>
> Issue 3584, deleting a grandchild of a copied parent creates a base
> node:
>
> svnadmin create repo
> svn import -mm Makefile file://`pwd`/repo/A/B/f
> svn co file://`pwd`/repo wc
> svn cp wc/A wc/A2
> svn rm wc/A2/B/f
>
> Your new code doesn't fix that:
My current code is just a copy of the old code, moved to a new location. No
fixes there. (It still uses svn_wc__entry_modify2).
In the rest of libsvn_wc we still rewrite BASE_NODE and WORKING_NODE records
from just the limited state in svn_wc_entry_t... and that would reintroduce
the issue anyway.
If we can fix this for the case where we write from the entries that would
be nice.
The real solution is stopping to write from entries, which takes much more
effort.
(I counted at least a dozen cases where we still change the scheduling via
entries yesterday... And then there are all those other calls for other
changes).
I would suggest focusing on removing those entry write operations before we
can focus on the nicest format in the database.
It happens to work in most cases now... (And in some cases for the wrong
reasons)
But we really need all that other work before we can switch pristines; move
to a single database; etc. etc.
(I'm hoping that removing those schedule+copied change operations will allow
a hack to switch to pristines sooner; but only time will tell if that is
going to work)
And only after all those steps we can go for 1.7. Or we have to cut WC-NG
completely out of the release.
Bert Huijben
Received on 2010-02-18 12:08:09 CET