RE: svn commit: r1092660 - in /subversion/trunk/subversion/libsvn_wc: adm_ops.c crop.c wc_db.c wc_db.h

> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: vrijdag 15 april 2011 22:00
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1092660 - in
> /subversion/trunk/subversion/libsvn_wc: adm_ops.c crop.c wc_db.c
> wc_db.h

> But I still don't think this change is right. You immediately remove
> nodes, or you queue up a commit operation (in order to batch the
> entire commit). What am I missing here?

The rest of the batch of commits ;-)

I started by moving that remove deleted operation which had to be loggy in
the entries+access baton world, but is 100% database now. (We don't leave
directories with data, to be removed later).

This is essentialy the db-only side of svn_wc_remove_from_revision_control2,
which is just a recursive delete

So this handles committing svn_wc__db_status_deleted.

And I replaced the queuing of this operation with performing this operation
itself. (We explicitly ran the wq to avoid recursing over deleted nodes. So
this was a safe change)

Then I handled the specialized case where we shadow nodes. (The old
'replaced' and the new cases where we can have more than 2 layers). I moved
this into the db_op, as it is a very easy recursive sql operation: Delete
all nodes at shadowed op_depths.
This is a safe operation once the op_root defining the old top level
operation is committed (read: moved to BASE / op_depth 0). And that happens
in the same transaction.

And then we had just two commit operations left:
svn_wc__db_status_added and svn_wc__db_status_normal.

And you already implemented the support for these two operations in wc_db
:-)

Before my patches, the commit for these statee was handled in the
post_commit wq operation:

- This fetched old information from the db
- Changed the DB
- Applied differences to the working copy.

This order of events made it a not restartable wq operation. (Once the db is
changed, the differences may be lost)

In r1092708, I changed this into a wq operation with only these steps:
- Fetch information
- Change the DB *and* install wq operation.
And a separate wq operation for applying.

But with that change it was also possible to do the fetch, change and
install outside the wq.

So that is the change I applied in r1092712.

(And then Mark Phippard ran into a few problems in svn_client_commit, which
I tried to solve in the last hour before rushing to the daycare for my
children...)

        Bert
Received on 2011-04-15 22:20:49 CEST