On Mon, Apr 25, 2011 at 6:03 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: hwright_at_apache.org [mailto:hwright_at_apache.org]
>> Sent: maandag 25 april 2011 23:59
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1096619 - in /subversion/trunk/subversion/libsvn_wc:
>> translate.c translate.h workqueue.c
>>
>> Author: hwright
>> Date: Mon Apr 25 21:58:43 2011
>> New Revision: 1096619
>>
>> URL: http://svn.apache.org/viewvc?rev=1096619&view=rev
>> Log:
>> Create a single unified function to sync file permissions with those indicated
>> by locks and various properties. Use it in post-commit and other processing.
>>
>> Note: this removes a couple of "optimizations" in the post-commit work
>> queue
>> handler. However, in doing so, we greatly simplify the code, and actually
>> *reduce* the number of overall database accesses, which should actually
>> speed
>> things up.
>
> Before this patch we didn't change permissions on files that had non-standard permissions.
>
> After this patch we force our set of permissions on the file. (Removing read-only in almost every case)
>
> I would call that a behavior change; but at least it should be documented.
True. I guess maybe I'm trying to shoehorn something in here that
doesn't belong. The end goal is to use the work queue to set
read-only and execute flags from propset, not just the current
commit/update/revert. Maybe what really needs to happen is a separate
work queue operation.
Which kinda irks me, actually. You'd think something as simple as
"ensure the permissions on disk match what's in the db" would be
fairly straightforward, but it ends up have all kinds of special cases
and various shortcuts. In some ways, I guess I'd settle for all of
the logic being encapsulated in a single function/set-of-functions,
rather than being spread across half-a-dozen functions and two files.
As a first step, then, it'd be nice to know what special handling is
needed for commit/update/revert, as opposed to propset. I'm happy to
go digging, but any insights others have would be useful.
> It looks like your patch doesn't break old wq items, but it writes new wq items that the old code can't read. (It removes the two booleans that specify the needs-lock and executable state before the propchange which allowed it to see the difference)
Fixed in r1096641.
-Hyrum
Received on 2011-04-26 03:06:47 CEST