> -----Original Message-----
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: donderdag 18 februari 2010 13:54
> To: Bert Huijben
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r909093 - in
> /subversion/trunk/subversion/libsvn_wc: adm_ops.c workqueue.c
> workqueue.h
>
> "Bert Huijben" <b...@qqmail.nl> writes:
>
> > 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.
>
> My plan was to write a svn_wc__db_temp_op_delete that modified the
> WORKING_NODE table directly, without calling entry_modify2. I have
> such a patch but it doesn't handle all the cases where delete can be
> called. It was the complexity of this that lead me to create the file
> notes/wc-ng/transitions--that's my attempt at describing what
> svn_wc__db_temp_op_delete should do.
I made the entry based intermediate function as a first step. To find out
what that operation should do to handle the strange cases and to allow
implementing the wc-db version in incremental steps.
This allows handling the easy cases the new way before switching the hard
cases. (Small steps towards the final solution)
> One other thing that worries me is that mark_tree_deleted seems to
> doing deletes without doing the loggy/workqueue stuff. If I delete a
> replaced file svn_wc_delete4 sets up a workqueue item to handle the
> text-bases. However if I delete a directory containing a replaced
> file it handles the file with a simple call to entry_modify2--that
> can't be right. It's not a new bug, it pre-dates wc-ng, but it means
> that the entry_modify2 calls in mark_tree_deleted cannot simply be
> replaced by svn_wc__db_temp_op_delete, we need to setup wq items in
> some cases.
In WC-1.0 we left old administrative data in a lot of code paths... (not
just a few :( ) and in most cases we fix this on adding.
(Talk about broken behavior...)
In the final version of WC-NG we don't need most of these operations any
more.
* Properties: In DB only. Handled directly. No loggy operation necessary
* Pristines: Not associated with a single file. No need to remove it in the
general case. (Maybe schedule a cleanup check as wq item?)
Where the old code 'happens to work' in the intermediate state I wouldn't
try to solve it cleanly for the period until we have the pristines working.
(All that work will have to go to /dev/null before 1.7)
Bert
