On Tue, Feb 8, 2011 at 1:41 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Hyrum K Wright wrote on Mon, Feb 07, 2011 at 23:14:10 +0000:
>> On Fri, Feb 4, 2011 at 4:36 PM, Noorul Islam K M <noorul_at_collab.net> wrote:
>> > hwright noorul: ignored_props_mod takes a list of properties, yes (as
>> > opposed to a blanket "ignore all prop mods")
>> >
>> > hwright what you are saying
>> > is that in order to accomplish the later
>> > with the former, you'd have to know a priori which props are in
>> > the repo, right?
>> >
>> > Yes, you are right. This is what I was trying to convey.
>>
>> Thanks for helping me understand. These two seem like a couple of
>> separate, but related, use cases. I wonder if there is a way to
>> convey "all properties" through the ignored-props list (perhaps a
>> special "svn:*" prop?).
>>
>
> Having a meta-entry in the property list sounds like a hack, could we
> easily have a cleaner design?
Well, we are allowed to define any props we want in the 'svn:'
namespace, and it does make sense (in some cases) to have a 'wildcard'
property. Maybe this is one of those?
>> For both case, though, I'd like some input from the peanut gallery,
>> commenting on the utility of adding code vs. maintenance, etc.
>>
>
> From the peanut gallery: having an "ignore any and all prop mods" sounds
> useful to me. How hard would it be to implement? Just marshal an
> additional flag and then skip a strcmp() in the FS library, or more
> involved?
The "skip any and all prop mods" functionality is actually easier than
the "skip selective prop mods" functionality because of the way we
store history in the FS and walk history in the repos. Long story
short: knowing that there was a prop mod is almost a free operation
(in the context of other stuff); finding out *what* was modified (and
therefore what should be filtered) takes a bit more work.
-Hyrum
Received on 2011-02-08 03:33:15 CET