You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Noorul Islam K M <no...@collab.net> on 2011/01/27 08:04:08 UTC
Regarding issue 3690
Hi,
I am planning to work on issue 3690. Before starting with this I have
few questions.
1. Hyrum updated the issue with his comment stating that already there
is work going on in the branch ignore-mergeinfo which addresses
subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
svn:mergeinfo an svn property set using svn pset command? I think Zvi
Rackover is talking about a new option passing which a user can
ignore revisions with just the following property changes alone.
author eol-style externals keywords mime-type
date executable ignore log needs-lock
2. Zvi is talking about log command alone in the issue. I assume that we
need this option only for log command.
Any comments?
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Noorul Islam K M <no...@collab.net> writes:
> Hyrum K Wright <hy...@hyrumwright.org> writes:
>
>> On Mon, Jan 31, 2011 at 10:52 PM, Noorul Islam K M <no...@collab.net> wrote:
>>
>>> Hyrum K Wright <hy...@hyrumwright.org> writes:
>>>
>>>> On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
>>>>
>>>>> Daniel Becroft <dj...@gmail.com> writes:
>>>>>
>>>>>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am planning to work on issue 3690. Before starting with this I have
>>>>>>> few questions.
>>>>>>>
>>>>>>> 1. Hyrum updated the issue with his comment stating that already there
>>>>>>> is work going on in the branch ignore-mergeinfo which addresses
>>>>>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>>>>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>>>>>> Rackover is talking about a new option passing which a user can
>>>>>>> ignore revisions with just the following property changes alone.
>>>>>>>
>>>>>>> author eol-style externals keywords mime-type
>>>>>>> date executable ignore log needs-lock
>>>>>>
>>>>>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>> Sent from my phone.
>>>>>>
>>>>>
>>>>> I started working on this and I think I completed the changes for
>>>>> svn_ra_local. Attached is the patch. This is a work in progress. I would
>>>>> like to get some initial comments/suggestions on the patch and would
>>>>> like to know whether I am proceeding on right direction.
>>>>>
>>>>> This patch adds new option '--ignore-properties' to 'log' sub
>>>>> command. If this option is provided then command ignore revisions that
>>>>> has only property changes from output.
>>>>
>>>> I haven't reviewed the patch, but would like to discuss the approach.
>>>>
>>>> Ignoring all or none of a set of prop mods may not be granular enough.
>>>> Since consumers rarely change mergeinfo without changing content, I
>>>> don't see that the new behavior would be exercised very often. What
>>>> we really want to do is filter out mergeinfo changes on a per-node
>>>> basis, not a per-revision basis as the new docs claim. (Perhaps the
>>>> docs are inaccurate?)
>>>>
>>>> I don't see anywhere in the patch where you address RA layers other
>>>> than ra_local. Also, what is the expected behavior when operating
>>>
>>> I mentioned this in the mail. I will be handling this in the future. I
>>> just wanted get feedback from list so that I might not end up direction
>>> less.
>>>
>>>> against older servers? If you send the ignore_properties flag to
>>>> older servers, they will just ignore the flag and return all the
>>>> revisions, and the client will dutifully report them. Do you have a
>>>> plan for this scenario?
>>>
>>> Thank you for pointing this out. So far I have not thought about
>>> this. What about throwing an error, if there the server version is less
>>> than what we expect?
>>
>> Or more specifically, if the server doesn't support the required
>> capability (as on the ignore-mergeinfo-log branch).
>>
>
> I will copy this :)
>
>>>> Finally, is there a reason why you chose to do this against trunk,
>>>> rather than the ignore-mergeinfo-log branch, which already addresses
>>>> many of the above concerns? I've been hacking on that branch a bit
>>>> lately, and it isn't complete but patches and review are definitely
>>>> welcome.
>>>>
>>>
>>> I did this against trunk because I could see lots of changes in
>>> ignore-mergeinfo-log branch. For me to avoid confusion, I thought I will
>>> start preparing patch against trunk. Also if I include this option also
>>> to the ignore-mergeinfo-log branch, will that be possible to factor out
>>> my changes alone? Or is it a good idea to have a separate branch for
>>> this. I am not sure at this point.
>>>
>>> Do you mean to say that ignore-mergeinfo-log has an option to filter out
>>> revisions being send to the receiver if that revision contains only
>>> property changes? Isn't that issue 3690 all about?
>>
>> Well, reading back through issue 3690, it looks like it could use some
>> design work. :)
>>
>> The reporter states the request, and then this motivation: "many users
>> are not interested in reviewing changes to property changes and only
>> care about content changes." To that I would ask "why?" What
>> scenarios does this pop up in.
>>
>> I know my specific usecase is managing the release branches, and
>> having to filter through all the svn:mergeinfo mods when attempting to
>> find the last time CHANGES was textually modified. Maybe that would
>> be accomplished by a 'ignore all prop mods' flag; maybe not. Maybe
>> the approach on the ignore-mergeinfo-log branch is *too* discrete, and
>> would end up being a performance killer; maybe not. The more I write,
>> the the more I think this deserves some design consideration. (And
>> hence my desire to do it on a branch rather than trunk: I don't want
>> to hold up 1.7, and don't want to release a half-cooked idea.)
>>
>> One other option may be to have some way of using the ignored prop mod
>> list, as on the branch, to specify ignoring *all* prop mods,
>> irrespective of property name. From an API perspective, this could
>> accomplish both goals. But I still think we need to think more about
>> what problem we're trying to solve.
>
> I will create this patch against ignore-mergeinfo-log branch. I will
> make the changes as you did for ignore-mergeinfo one by one. Attached is
> the first patch which adds the option to log sub command. It will be
> great if you could review them and let me know the comments.
>
Log
[[[
On the ignore-mergeinfo-log branch:
* subversion/tests/cmdline/getopt_tests_data/svn_help_log_switch_stdout:
Add extra ignore-properties help text.
]]]
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Noorul Islam K M <no...@collab.net> writes:
> Hyrum K Wright <hy...@hyrumwright.org> writes:
>
>> On Mon, Jan 31, 2011 at 10:52 PM, Noorul Islam K M <no...@collab.net> wrote:
>>
>>> Hyrum K Wright <hy...@hyrumwright.org> writes:
>>>
>>>> On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
>>>>
>>>>> Daniel Becroft <dj...@gmail.com> writes:
>>>>>
>>>>>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am planning to work on issue 3690. Before starting with this I have
>>>>>>> few questions.
>>>>>>>
>>>>>>> 1. Hyrum updated the issue with his comment stating that already there
>>>>>>> is work going on in the branch ignore-mergeinfo which addresses
>>>>>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>>>>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>>>>>> Rackover is talking about a new option passing which a user can
>>>>>>> ignore revisions with just the following property changes alone.
>>>>>>>
>>>>>>> author eol-style externals keywords mime-type
>>>>>>> date executable ignore log needs-lock
>>>>>>
>>>>>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>> Sent from my phone.
>>>>>>
>>>>>
>>>>> I started working on this and I think I completed the changes for
>>>>> svn_ra_local. Attached is the patch. This is a work in progress. I would
>>>>> like to get some initial comments/suggestions on the patch and would
>>>>> like to know whether I am proceeding on right direction.
>>>>>
>>>>> This patch adds new option '--ignore-properties' to 'log' sub
>>>>> command. If this option is provided then command ignore revisions that
>>>>> has only property changes from output.
>>>>
>>>> I haven't reviewed the patch, but would like to discuss the approach.
>>>>
>>>> Ignoring all or none of a set of prop mods may not be granular enough.
>>>> Since consumers rarely change mergeinfo without changing content, I
>>>> don't see that the new behavior would be exercised very often. What
>>>> we really want to do is filter out mergeinfo changes on a per-node
>>>> basis, not a per-revision basis as the new docs claim. (Perhaps the
>>>> docs are inaccurate?)
>>>>
>>>> I don't see anywhere in the patch where you address RA layers other
>>>> than ra_local. Also, what is the expected behavior when operating
>>>
>>> I mentioned this in the mail. I will be handling this in the future. I
>>> just wanted get feedback from list so that I might not end up direction
>>> less.
>>>
>>>> against older servers? If you send the ignore_properties flag to
>>>> older servers, they will just ignore the flag and return all the
>>>> revisions, and the client will dutifully report them. Do you have a
>>>> plan for this scenario?
>>>
>>> Thank you for pointing this out. So far I have not thought about
>>> this. What about throwing an error, if there the server version is less
>>> than what we expect?
>>
>> Or more specifically, if the server doesn't support the required
>> capability (as on the ignore-mergeinfo-log branch).
>>
>
> I will copy this :)
>
>>>> Finally, is there a reason why you chose to do this against trunk,
>>>> rather than the ignore-mergeinfo-log branch, which already addresses
>>>> many of the above concerns? I've been hacking on that branch a bit
>>>> lately, and it isn't complete but patches and review are definitely
>>>> welcome.
>>>>
>>>
>>> I did this against trunk because I could see lots of changes in
>>> ignore-mergeinfo-log branch. For me to avoid confusion, I thought I will
>>> start preparing patch against trunk. Also if I include this option also
>>> to the ignore-mergeinfo-log branch, will that be possible to factor out
>>> my changes alone? Or is it a good idea to have a separate branch for
>>> this. I am not sure at this point.
>>>
>>> Do you mean to say that ignore-mergeinfo-log has an option to filter out
>>> revisions being send to the receiver if that revision contains only
>>> property changes? Isn't that issue 3690 all about?
>>
>> Well, reading back through issue 3690, it looks like it could use some
>> design work. :)
>>
>> The reporter states the request, and then this motivation: "many users
>> are not interested in reviewing changes to property changes and only
>> care about content changes." To that I would ask "why?" What
>> scenarios does this pop up in.
>>
>> I know my specific usecase is managing the release branches, and
>> having to filter through all the svn:mergeinfo mods when attempting to
>> find the last time CHANGES was textually modified. Maybe that would
>> be accomplished by a 'ignore all prop mods' flag; maybe not. Maybe
>> the approach on the ignore-mergeinfo-log branch is *too* discrete, and
>> would end up being a performance killer; maybe not. The more I write,
>> the the more I think this deserves some design consideration. (And
>> hence my desire to do it on a branch rather than trunk: I don't want
>> to hold up 1.7, and don't want to release a half-cooked idea.)
>>
>> One other option may be to have some way of using the ignored prop mod
>> list, as on the branch, to specify ignoring *all* prop mods,
>> irrespective of property name. From an API perspective, this could
>> accomplish both goals. But I still think we need to think more about
>> what problem we're trying to solve.
>
> I will create this patch against ignore-mergeinfo-log branch. I will
> make the changes as you did for ignore-mergeinfo one by one. Attached is
> the first patch which adds the option to log sub command. It will be
> great if you could review them and let me know the comments.
>
Log
[[[
On the ignore-mergeinfo-log branch:
Add a simple test of ignoring revisions with only property changes.
* subversion/tests/cmdline/log_tests.py
(log_ignore_properties): New.
(test_list): Run the new test as XFail.
]]]
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Hyrum K Wright <hy...@hyrumwright.org> writes:
> On Mon, Jan 31, 2011 at 10:52 PM, Noorul Islam K M <no...@collab.net> wrote:
>
>> Hyrum K Wright <hy...@hyrumwright.org> writes:
>>
>>> On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
>>>
>>>> Daniel Becroft <dj...@gmail.com> writes:
>>>>
>>>>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am planning to work on issue 3690. Before starting with this I have
>>>>>> few questions.
>>>>>>
>>>>>> 1. Hyrum updated the issue with his comment stating that already there
>>>>>> is work going on in the branch ignore-mergeinfo which addresses
>>>>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>>>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>>>>> Rackover is talking about a new option passing which a user can
>>>>>> ignore revisions with just the following property changes alone.
>>>>>>
>>>>>> author eol-style externals keywords mime-type
>>>>>> date executable ignore log needs-lock
>>>>>
>>>>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>> Sent from my phone.
>>>>>
>>>>
>>>> I started working on this and I think I completed the changes for
>>>> svn_ra_local. Attached is the patch. This is a work in progress. I would
>>>> like to get some initial comments/suggestions on the patch and would
>>>> like to know whether I am proceeding on right direction.
>>>>
>>>> This patch adds new option '--ignore-properties' to 'log' sub
>>>> command. If this option is provided then command ignore revisions that
>>>> has only property changes from output.
>>>
>>> I haven't reviewed the patch, but would like to discuss the approach.
>>>
>>> Ignoring all or none of a set of prop mods may not be granular enough.
>>> Since consumers rarely change mergeinfo without changing content, I
>>> don't see that the new behavior would be exercised very often. What
>>> we really want to do is filter out mergeinfo changes on a per-node
>>> basis, not a per-revision basis as the new docs claim. (Perhaps the
>>> docs are inaccurate?)
>>>
>>> I don't see anywhere in the patch where you address RA layers other
>>> than ra_local. Also, what is the expected behavior when operating
>>
>> I mentioned this in the mail. I will be handling this in the future. I
>> just wanted get feedback from list so that I might not end up direction
>> less.
>>
>>> against older servers? If you send the ignore_properties flag to
>>> older servers, they will just ignore the flag and return all the
>>> revisions, and the client will dutifully report them. Do you have a
>>> plan for this scenario?
>>
>> Thank you for pointing this out. So far I have not thought about
>> this. What about throwing an error, if there the server version is less
>> than what we expect?
>
> Or more specifically, if the server doesn't support the required
> capability (as on the ignore-mergeinfo-log branch).
>
I will copy this :)
>>> Finally, is there a reason why you chose to do this against trunk,
>>> rather than the ignore-mergeinfo-log branch, which already addresses
>>> many of the above concerns? I've been hacking on that branch a bit
>>> lately, and it isn't complete but patches and review are definitely
>>> welcome.
>>>
>>
>> I did this against trunk because I could see lots of changes in
>> ignore-mergeinfo-log branch. For me to avoid confusion, I thought I will
>> start preparing patch against trunk. Also if I include this option also
>> to the ignore-mergeinfo-log branch, will that be possible to factor out
>> my changes alone? Or is it a good idea to have a separate branch for
>> this. I am not sure at this point.
>>
>> Do you mean to say that ignore-mergeinfo-log has an option to filter out
>> revisions being send to the receiver if that revision contains only
>> property changes? Isn't that issue 3690 all about?
>
> Well, reading back through issue 3690, it looks like it could use some
> design work. :)
>
> The reporter states the request, and then this motivation: "many users
> are not interested in reviewing changes to property changes and only
> care about content changes." To that I would ask "why?" What
> scenarios does this pop up in.
>
> I know my specific usecase is managing the release branches, and
> having to filter through all the svn:mergeinfo mods when attempting to
> find the last time CHANGES was textually modified. Maybe that would
> be accomplished by a 'ignore all prop mods' flag; maybe not. Maybe
> the approach on the ignore-mergeinfo-log branch is *too* discrete, and
> would end up being a performance killer; maybe not. The more I write,
> the the more I think this deserves some design consideration. (And
> hence my desire to do it on a branch rather than trunk: I don't want
> to hold up 1.7, and don't want to release a half-cooked idea.)
>
> One other option may be to have some way of using the ignored prop mod
> list, as on the branch, to specify ignoring *all* prop mods,
> irrespective of property name. From an API perspective, this could
> accomplish both goals. But I still think we need to think more about
> what problem we're trying to solve.
I will create this patch against ignore-mergeinfo-log branch. I will
make the changes as you did for ignore-mergeinfo one by one. Attached is
the first patch which adds the option to log sub command. It will be
great if you could review them and let me know the comments.
Log
[[[
Add the ignore_properties flag to the command line client, and let 'svn
log' accept it. Don't actually do anything with it yet.
* BRANCH-README: Add ignore-properties task list.
* subversion/svn/cl.h
(svn_cl__opt_state_t): New ignore_properties member.
* subversion/svn/main.c
(svn_cl__longopt_t): Add opt_ignore_properties member.
(svn_cl__options): Document the ignore-properties flag.
(svn_cl__cmd_table): Accept ignore-properties for log operations.
(main): If given --ignore-properties, set the option flag to TRUE.
]]]
>
> Incidentally, I like the issue number: 3690. For bonus points, can
> anybody tell my why that number is significant in Subversion-land? :)
>
> -Hyrum
>
> PS - Sorry if I was a bit harsh in the last mail.
No problems.
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Gavin Beau Baumanis <ga...@thespidernet.com> writes:
> Ping. This submission has not received any further comments.
>
> Specifically, Noorul seems to be after comments about "this";
> http://svn.haxx.se/dev/archive-2011-01/0537.shtml , post.
>
>
> On 14/02/2011, at 6:41 PM, Noorul Islam K M wrote:
>
>> Noorul Islam K M <no...@collab.net> writes:
>>
>>> Hyrum K Wright <hy...@hyrumwright.org> writes:
>>>
>>>> On Tue, Feb 8, 2011 at 1:41 AM, Daniel Shahaf <d....@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 <no...@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/Daniel,
>>>
>>> Do you think the initial approach that I took in the following thread is
>>> good enough to implement --ignore-properties? I think it is a very
>>> straight forward implementation. Please take a look.
>>>
>>> http://svn.haxx.se/dev/archive-2011-01/0537.shtml
>>>
>>
>> I would like to proceed with my initial approach. I think it will be
>> great to submit series of patches against trunk. Or may be a new private
>> branch? Please let me know your comments.
>>
>> Thanks and Regards
>> Noorul
>>
Since everyone is busy with 1.7 release. This is parked for the time
being. I hope this thread will get more attention once 1.7 is out.
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Gavin Beau Baumanis <ga...@thespidernet.com>.
Ping. This submission has not received any further comments.
Specifically, Noorul seems to be after comments about "this";
http://svn.haxx.se/dev/archive-2011-01/0537.shtml , post.
On 14/02/2011, at 6:41 PM, Noorul Islam K M wrote:
> Noorul Islam K M <no...@collab.net> writes:
>
>> Hyrum K Wright <hy...@hyrumwright.org> writes:
>>
>>> On Tue, Feb 8, 2011 at 1:41 AM, Daniel Shahaf <d....@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 <no...@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/Daniel,
>>
>> Do you think the initial approach that I took in the following thread is
>> good enough to implement --ignore-properties? I think it is a very
>> straight forward implementation. Please take a look.
>>
>> http://svn.haxx.se/dev/archive-2011-01/0537.shtml
>>
>
> I would like to proceed with my initial approach. I think it will be
> great to submit series of patches against trunk. Or may be a new private
> branch? Please let me know your comments.
>
> Thanks and Regards
> Noorul
>
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Noorul Islam K M <no...@collab.net> writes:
> Hyrum K Wright <hy...@hyrumwright.org> writes:
>
>> On Tue, Feb 8, 2011 at 1:41 AM, Daniel Shahaf <d....@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 <no...@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/Daniel,
>
> Do you think the initial approach that I took in the following thread is
> good enough to implement --ignore-properties? I think it is a very
> straight forward implementation. Please take a look.
>
> http://svn.haxx.se/dev/archive-2011-01/0537.shtml
>
I would like to proceed with my initial approach. I think it will be
great to submit series of patches against trunk. Or may be a new private
branch? Please let me know your comments.
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Hyrum K Wright <hy...@hyrumwright.org> writes:
> On Tue, Feb 8, 2011 at 1:41 AM, Daniel Shahaf <d....@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 <no...@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/Daniel,
Do you think the initial approach that I took in the following thread is
good enough to implement --ignore-properties? I think it is a very
straight forward implementation. Please take a look.
http://svn.haxx.se/dev/archive-2011-01/0537.shtml
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, Feb 8, 2011 at 1:41 AM, Daniel Shahaf <d....@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 <no...@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
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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 <no...@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?
> 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?
> -Hyrum
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Fri, Feb 4, 2011 at 4:36 PM, Noorul Islam K M <no...@collab.net> wrote:
> "noorul Islam. Kamal Malmiyoda" <no...@collab.net> writes:
>
>> On Feb 3, 2011, at 5:39 AM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>>
>>> On Wed, Feb 2, 2011 at 6:29 AM, Noorul Islam K M <no...@collab.net> wrote:
>>>>
>>>> Is ignored_prop_mods list functionality completely implemented?
>>>
>>> Not yet. I've got all the boiler-plate done, but have not yet added
>>> the extra filtering in libsvn_repos. Because 'log' is a small part of
>>> the overall feature set, and I'm hesitant to release bits of it
>>> without the rest, I don't anticipate having this done for 1.7, and am
>>> not in to terrible a rush to get it done (now).
>>>
>>>> I assume that we can set any property to a target not necessarily what
>>>> is pre-defined by svn. For example.
>>>>
>>>> $ svn ps foo bar file.txt
>>>>
>>>> I think this is a valid command. In this case how will ignore_prop_mods
>>>> list be useful? Are you planning to handle this scenario? Am I
>>>> overlooking?
>>>
>>> I'm trying to implement the functionality in as flexible a way as
>>> possible. Some might argue that this is over-engineering, but I think
>>> that by allowing an arbitrary list of ignored props for operations
>>> like 'log' and 'diff', that gives flexibility to other tools which
>>> create and consume their own properties.
>>>
>>> For example, if TortoiseSVN, or some other third-party tool creates
>>> its own properties for tracking information, it could just as easily
>>> filter these properties out when calling the log APIs, thus making
>>> them practically transparent to the end user. (We can debate whether
>>> such transparency is desirable, but I think well-behaving
>>> implementations will use this functionality to get out of the way,
>>> without making things too magical.)
>>>
>>> Since your example doesn't use 'log', and 'log' is the only command
>>> effected at this point, I'm not entirely sure what your question is.
>>>
>>
>> With the above command a user can set any property for a target. Now say I want to make use of ignored_props_mod to filter out this arbitrary property, will that be possible?
>>
>
> From IRC
>
> noorul hwright: hello
>
> noorul hwright: I think for 3690, ignored_props_mod might not be useful
> because it takes a predefined set of properties noorul hwright: See my
> reply
>
> 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?).
For both case, though, I'd like some input from the peanut gallery,
commenting on the utility of adding code vs. maintenance, etc.
-Hyrum
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
"noorul Islam. Kamal Malmiyoda" <no...@collab.net> writes:
> On Feb 3, 2011, at 5:39 AM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>
>> On Wed, Feb 2, 2011 at 6:29 AM, Noorul Islam K M <no...@collab.net> wrote:
>>>
>>> Is ignored_prop_mods list functionality completely implemented?
>>
>> Not yet. I've got all the boiler-plate done, but have not yet added
>> the extra filtering in libsvn_repos. Because 'log' is a small part of
>> the overall feature set, and I'm hesitant to release bits of it
>> without the rest, I don't anticipate having this done for 1.7, and am
>> not in to terrible a rush to get it done (now).
>>
>>> I assume that we can set any property to a target not necessarily what
>>> is pre-defined by svn. For example.
>>>
>>> $ svn ps foo bar file.txt
>>>
>>> I think this is a valid command. In this case how will ignore_prop_mods
>>> list be useful? Are you planning to handle this scenario? Am I
>>> overlooking?
>>
>> I'm trying to implement the functionality in as flexible a way as
>> possible. Some might argue that this is over-engineering, but I think
>> that by allowing an arbitrary list of ignored props for operations
>> like 'log' and 'diff', that gives flexibility to other tools which
>> create and consume their own properties.
>>
>> For example, if TortoiseSVN, or some other third-party tool creates
>> its own properties for tracking information, it could just as easily
>> filter these properties out when calling the log APIs, thus making
>> them practically transparent to the end user. (We can debate whether
>> such transparency is desirable, but I think well-behaving
>> implementations will use this functionality to get out of the way,
>> without making things too magical.)
>>
>> Since your example doesn't use 'log', and 'log' is the only command
>> effected at this point, I'm not entirely sure what your question is.
>>
>
> With the above command a user can set any property for a target. Now say I want to make use of ignored_props_mod to filter out this arbitrary property, will that be possible?
>
>From IRC
noorul hwright: hello
noorul hwright: I think for 3690, ignored_props_mod might not be useful
because it takes a predefined set of properties noorul hwright: See my
reply
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 and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by "noorul Islam. Kamal Malmiyoda" <no...@collab.net>.
On Feb 3, 2011, at 5:39 AM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
> On Wed, Feb 2, 2011 at 6:29 AM, Noorul Islam K M <no...@collab.net> wrote:
>>
>> Is ignored_prop_mods list functionality completely implemented?
>
> Not yet. I've got all the boiler-plate done, but have not yet added
> the extra filtering in libsvn_repos. Because 'log' is a small part of
> the overall feature set, and I'm hesitant to release bits of it
> without the rest, I don't anticipate having this done for 1.7, and am
> not in to terrible a rush to get it done (now).
>
>> I assume that we can set any property to a target not necessarily what
>> is pre-defined by svn. For example.
>>
>> $ svn ps foo bar file.txt
>>
>> I think this is a valid command. In this case how will ignore_prop_mods
>> list be useful? Are you planning to handle this scenario? Am I
>> overlooking?
>
> I'm trying to implement the functionality in as flexible a way as
> possible. Some might argue that this is over-engineering, but I think
> that by allowing an arbitrary list of ignored props for operations
> like 'log' and 'diff', that gives flexibility to other tools which
> create and consume their own properties.
>
> For example, if TortoiseSVN, or some other third-party tool creates
> its own properties for tracking information, it could just as easily
> filter these properties out when calling the log APIs, thus making
> them practically transparent to the end user. (We can debate whether
> such transparency is desirable, but I think well-behaving
> implementations will use this functionality to get out of the way,
> without making things too magical.)
>
> Since your example doesn't use 'log', and 'log' is the only command
> effected at this point, I'm not entirely sure what your question is.
>
With the above command a user can set any property for a target. Now say I want to make use of ignored_props_mod to filter out this arbitrary property, will that be possible?
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Feb 2, 2011 at 6:29 AM, Noorul Islam K M <no...@collab.net> wrote:
>
> Is ignored_prop_mods list functionality completely implemented?
Not yet. I've got all the boiler-plate done, but have not yet added
the extra filtering in libsvn_repos. Because 'log' is a small part of
the overall feature set, and I'm hesitant to release bits of it
without the rest, I don't anticipate having this done for 1.7, and am
not in to terrible a rush to get it done (now).
> I assume that we can set any property to a target not necessarily what
> is pre-defined by svn. For example.
>
> $ svn ps foo bar file.txt
>
> I think this is a valid command. In this case how will ignore_prop_mods
> list be useful? Are you planning to handle this scenario? Am I
> overlooking?
I'm trying to implement the functionality in as flexible a way as
possible. Some might argue that this is over-engineering, but I think
that by allowing an arbitrary list of ignored props for operations
like 'log' and 'diff', that gives flexibility to other tools which
create and consume their own properties.
For example, if TortoiseSVN, or some other third-party tool creates
its own properties for tracking information, it could just as easily
filter these properties out when calling the log APIs, thus making
them practically transparent to the end user. (We can debate whether
such transparency is desirable, but I think well-behaving
implementations will use this functionality to get out of the way,
without making things too magical.)
Since your example doesn't use 'log', and 'log' is the only command
effected at this point, I'm not entirely sure what your question is.
-Hyrum
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
I'm not Hyrum, but the log messages on the branch showed a list of
propnames that are to be ignored, so I assume this *will* be handled.
Noorul Islam K M wrote on Wed, Feb 02, 2011 at 17:59:15 +0530:
> Is ignored_prop_mods list functionality completely implemented?
>
> I assume that we can set any property to a target not necessarily what
> is pre-defined by svn. For example.
>
> $ svn ps foo bar file.txt
>
> I think this is a valid command. In this case how will ignore_prop_mods
> list be useful? Are you planning to handle this scenario? Am I
> overlooking?
>
> Thanks and Regards
> Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Hyrum K Wright <hy...@hyrumwright.org> writes:
> On Mon, Jan 31, 2011 at 10:52 PM, Noorul Islam K M <no...@collab.net> wrote:
>
>> Hyrum K Wright <hy...@hyrumwright.org> writes:
>>
>>> On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
>>>
>>>> Daniel Becroft <dj...@gmail.com> writes:
>>>>
>>>>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am planning to work on issue 3690. Before starting with this I have
>>>>>> few questions.
>>>>>>
>>>>>> 1. Hyrum updated the issue with his comment stating that already there
>>>>>> is work going on in the branch ignore-mergeinfo which addresses
>>>>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>>>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>>>>> Rackover is talking about a new option passing which a user can
>>>>>> ignore revisions with just the following property changes alone.
>>>>>>
>>>>>> author eol-style externals keywords mime-type
>>>>>> date executable ignore log needs-lock
>>>>>
>>>>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>> Sent from my phone.
>>>>>
>>>>
>>>> I started working on this and I think I completed the changes for
>>>> svn_ra_local. Attached is the patch. This is a work in progress. I would
>>>> like to get some initial comments/suggestions on the patch and would
>>>> like to know whether I am proceeding on right direction.
>>>>
>>>> This patch adds new option '--ignore-properties' to 'log' sub
>>>> command. If this option is provided then command ignore revisions that
>>>> has only property changes from output.
>>>
>>> I haven't reviewed the patch, but would like to discuss the approach.
>>>
>>> Ignoring all or none of a set of prop mods may not be granular enough.
>>> Since consumers rarely change mergeinfo without changing content, I
>>> don't see that the new behavior would be exercised very often. What
>>> we really want to do is filter out mergeinfo changes on a per-node
>>> basis, not a per-revision basis as the new docs claim. (Perhaps the
>>> docs are inaccurate?)
>>>
>>> I don't see anywhere in the patch where you address RA layers other
>>> than ra_local. Also, what is the expected behavior when operating
>>
>> I mentioned this in the mail. I will be handling this in the future. I
>> just wanted get feedback from list so that I might not end up direction
>> less.
>>
>>> against older servers? If you send the ignore_properties flag to
>>> older servers, they will just ignore the flag and return all the
>>> revisions, and the client will dutifully report them. Do you have a
>>> plan for this scenario?
>>
>> Thank you for pointing this out. So far I have not thought about
>> this. What about throwing an error, if there the server version is less
>> than what we expect?
>
> Or more specifically, if the server doesn't support the required
> capability (as on the ignore-mergeinfo-log branch).
>
>>> Finally, is there a reason why you chose to do this against trunk,
>>> rather than the ignore-mergeinfo-log branch, which already addresses
>>> many of the above concerns? I've been hacking on that branch a bit
>>> lately, and it isn't complete but patches and review are definitely
>>> welcome.
>>>
>>
>> I did this against trunk because I could see lots of changes in
>> ignore-mergeinfo-log branch. For me to avoid confusion, I thought I will
>> start preparing patch against trunk. Also if I include this option also
>> to the ignore-mergeinfo-log branch, will that be possible to factor out
>> my changes alone? Or is it a good idea to have a separate branch for
>> this. I am not sure at this point.
>>
>> Do you mean to say that ignore-mergeinfo-log has an option to filter out
>> revisions being send to the receiver if that revision contains only
>> property changes? Isn't that issue 3690 all about?
>
> Well, reading back through issue 3690, it looks like it could use some
> design work. :)
>
> The reporter states the request, and then this motivation: "many users
> are not interested in reviewing changes to property changes and only
> care about content changes." To that I would ask "why?" What
> scenarios does this pop up in.
>
> I know my specific usecase is managing the release branches, and
> having to filter through all the svn:mergeinfo mods when attempting to
> find the last time CHANGES was textually modified. Maybe that would
> be accomplished by a 'ignore all prop mods' flag; maybe not. Maybe
> the approach on the ignore-mergeinfo-log branch is *too* discrete, and
> would end up being a performance killer; maybe not. The more I write,
> the the more I think this deserves some design consideration. (And
> hence my desire to do it on a branch rather than trunk: I don't want
> to hold up 1.7, and don't want to release a half-cooked idea.)
>
> One other option may be to have some way of using the ignored prop mod
> list, as on the branch, to specify ignoring *all* prop mods,
> irrespective of property name. From an API perspective, this could
> accomplish both goals. But I still think we need to think more about
> what problem we're trying to solve.
>
Is ignored_prop_mods list functionality completely implemented?
I assume that we can set any property to a target not necessarily what
is pre-defined by svn. For example.
$ svn ps foo bar file.txt
I think this is a valid command. In this case how will ignore_prop_mods
list be useful? Are you planning to handle this scenario? Am I
overlooking?
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Jan 31, 2011 at 10:52 PM, Noorul Islam K M <no...@collab.net> wrote:
> Hyrum K Wright <hy...@hyrumwright.org> writes:
>
>> On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
>>
>>> Daniel Becroft <dj...@gmail.com> writes:
>>>
>>>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am planning to work on issue 3690. Before starting with this I have
>>>>> few questions.
>>>>>
>>>>> 1. Hyrum updated the issue with his comment stating that already there
>>>>> is work going on in the branch ignore-mergeinfo which addresses
>>>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>>>> Rackover is talking about a new option passing which a user can
>>>>> ignore revisions with just the following property changes alone.
>>>>>
>>>>> author eol-style externals keywords mime-type
>>>>> date executable ignore log needs-lock
>>>>
>>>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>>>
>>>> Cheers,
>>>> Daniel
>>>> Sent from my phone.
>>>>
>>>
>>> I started working on this and I think I completed the changes for
>>> svn_ra_local. Attached is the patch. This is a work in progress. I would
>>> like to get some initial comments/suggestions on the patch and would
>>> like to know whether I am proceeding on right direction.
>>>
>>> This patch adds new option '--ignore-properties' to 'log' sub
>>> command. If this option is provided then command ignore revisions that
>>> has only property changes from output.
>>
>> I haven't reviewed the patch, but would like to discuss the approach.
>>
>> Ignoring all or none of a set of prop mods may not be granular enough.
>> Since consumers rarely change mergeinfo without changing content, I
>> don't see that the new behavior would be exercised very often. What
>> we really want to do is filter out mergeinfo changes on a per-node
>> basis, not a per-revision basis as the new docs claim. (Perhaps the
>> docs are inaccurate?)
>>
>> I don't see anywhere in the patch where you address RA layers other
>> than ra_local. Also, what is the expected behavior when operating
>
> I mentioned this in the mail. I will be handling this in the future. I
> just wanted get feedback from list so that I might not end up direction
> less.
>
>> against older servers? If you send the ignore_properties flag to
>> older servers, they will just ignore the flag and return all the
>> revisions, and the client will dutifully report them. Do you have a
>> plan for this scenario?
>
> Thank you for pointing this out. So far I have not thought about
> this. What about throwing an error, if there the server version is less
> than what we expect?
Or more specifically, if the server doesn't support the required
capability (as on the ignore-mergeinfo-log branch).
>> Finally, is there a reason why you chose to do this against trunk,
>> rather than the ignore-mergeinfo-log branch, which already addresses
>> many of the above concerns? I've been hacking on that branch a bit
>> lately, and it isn't complete but patches and review are definitely
>> welcome.
>>
>
> I did this against trunk because I could see lots of changes in
> ignore-mergeinfo-log branch. For me to avoid confusion, I thought I will
> start preparing patch against trunk. Also if I include this option also
> to the ignore-mergeinfo-log branch, will that be possible to factor out
> my changes alone? Or is it a good idea to have a separate branch for
> this. I am not sure at this point.
>
> Do you mean to say that ignore-mergeinfo-log has an option to filter out
> revisions being send to the receiver if that revision contains only
> property changes? Isn't that issue 3690 all about?
Well, reading back through issue 3690, it looks like it could use some
design work. :)
The reporter states the request, and then this motivation: "many users
are not interested in reviewing changes to property changes and only
care about content changes." To that I would ask "why?" What
scenarios does this pop up in.
I know my specific usecase is managing the release branches, and
having to filter through all the svn:mergeinfo mods when attempting to
find the last time CHANGES was textually modified. Maybe that would
be accomplished by a 'ignore all prop mods' flag; maybe not. Maybe
the approach on the ignore-mergeinfo-log branch is *too* discrete, and
would end up being a performance killer; maybe not. The more I write,
the the more I think this deserves some design consideration. (And
hence my desire to do it on a branch rather than trunk: I don't want
to hold up 1.7, and don't want to release a half-cooked idea.)
One other option may be to have some way of using the ignored prop mod
list, as on the branch, to specify ignoring *all* prop mods,
irrespective of property name. From an API perspective, this could
accomplish both goals. But I still think we need to think more about
what problem we're trying to solve.
Incidentally, I like the issue number: 3690. For bonus points, can
anybody tell my why that number is significant in Subversion-land? :)
-Hyrum
PS - Sorry if I was a bit harsh in the last mail.
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Hyrum K Wright <hy...@hyrumwright.org> writes:
> On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
>
>> Daniel Becroft <dj...@gmail.com> writes:
>>
>>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am planning to work on issue 3690. Before starting with this I have
>>>> few questions.
>>>>
>>>> 1. Hyrum updated the issue with his comment stating that already there
>>>> is work going on in the branch ignore-mergeinfo which addresses
>>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>>> Rackover is talking about a new option passing which a user can
>>>> ignore revisions with just the following property changes alone.
>>>>
>>>> author eol-style externals keywords mime-type
>>>> date executable ignore log needs-lock
>>>
>>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>>
>>> Cheers,
>>> Daniel
>>> Sent from my phone.
>>>
>>
>> I started working on this and I think I completed the changes for
>> svn_ra_local. Attached is the patch. This is a work in progress. I would
>> like to get some initial comments/suggestions on the patch and would
>> like to know whether I am proceeding on right direction.
>>
>> This patch adds new option '--ignore-properties' to 'log' sub
>> command. If this option is provided then command ignore revisions that
>> has only property changes from output.
>
> I haven't reviewed the patch, but would like to discuss the approach.
>
> Ignoring all or none of a set of prop mods may not be granular enough.
> Since consumers rarely change mergeinfo without changing content, I
> don't see that the new behavior would be exercised very often. What
> we really want to do is filter out mergeinfo changes on a per-node
> basis, not a per-revision basis as the new docs claim. (Perhaps the
> docs are inaccurate?)
>
> I don't see anywhere in the patch where you address RA layers other
> than ra_local. Also, what is the expected behavior when operating
I mentioned this in the mail. I will be handling this in the future. I
just wanted get feedback from list so that I might not end up direction
less.
> against older servers? If you send the ignore_properties flag to
> older servers, they will just ignore the flag and return all the
> revisions, and the client will dutifully report them. Do you have a
> plan for this scenario?
Thank you for pointing this out. So far I have not thought about
this. What about throwing an error, if there the server version is less
than what we expect?
>
> Finally, is there a reason why you chose to do this against trunk,
> rather than the ignore-mergeinfo-log branch, which already addresses
> many of the above concerns? I've been hacking on that branch a bit
> lately, and it isn't complete but patches and review are definitely
> welcome.
>
I did this against trunk because I could see lots of changes in
ignore-mergeinfo-log branch. For me to avoid confusion, I thought I will
start preparing patch against trunk. Also if I include this option also
to the ignore-mergeinfo-log branch, will that be possible to factor out
my changes alone? Or is it a good idea to have a separate branch for
this. I am not sure at this point.
Do you mean to say that ignore-mergeinfo-log has an option to filter out
revisions being send to the receiver if that revision contains only
property changes? Isn't that issue 3690 all about?
> Anyway, these are my thoughts, I'm interested in what others have to say.
>
Yes, I am also looking for more suggestions and feedback.
Thanks and Regards
Noorul
Re: [PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Jan 31, 2011 at 10:53 AM, Noorul Islam K M <no...@collab.net> wrote:
> Daniel Becroft <dj...@gmail.com> writes:
>
>> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>>
>>> Hi,
>>>
>>> I am planning to work on issue 3690. Before starting with this I have
>>> few questions.
>>>
>>> 1. Hyrum updated the issue with his comment stating that already there
>>> is work going on in the branch ignore-mergeinfo which addresses
>>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>>> Rackover is talking about a new option passing which a user can
>>> ignore revisions with just the following property changes alone.
>>>
>>> author eol-style externals keywords mime-type
>>> date executable ignore log needs-lock
>>
>> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>>
>> Cheers,
>> Daniel
>> Sent from my phone.
>>
>
> I started working on this and I think I completed the changes for
> svn_ra_local. Attached is the patch. This is a work in progress. I would
> like to get some initial comments/suggestions on the patch and would
> like to know whether I am proceeding on right direction.
>
> This patch adds new option '--ignore-properties' to 'log' sub
> command. If this option is provided then command ignore revisions that
> has only property changes from output.
I haven't reviewed the patch, but would like to discuss the approach.
Ignoring all or none of a set of prop mods may not be granular enough.
Since consumers rarely change mergeinfo without changing content, I
don't see that the new behavior would be exercised very often. What
we really want to do is filter out mergeinfo changes on a per-node
basis, not a per-revision basis as the new docs claim. (Perhaps the
docs are inaccurate?)
I don't see anywhere in the patch where you address RA layers other
than ra_local. Also, what is the expected behavior when operating
against older servers? If you send the ignore_properties flag to
older servers, they will just ignore the flag and return all the
revisions, and the client will dutifully report them. Do you have a
plan for this scenario?
Finally, is there a reason why you chose to do this against trunk,
rather than the ignore-mergeinfo-log branch, which already addresses
many of the above concerns? I've been hacking on that branch a bit
lately, and it isn't complete but patches and review are definitely
welcome.
Anyway, these are my thoughts, I'm interested in what others have to say.
-Hyrum
[PATCH] Re: Regarding issue 3690 - Work in progress
Posted by Noorul Islam K M <no...@collab.net>.
Daniel Becroft <dj...@gmail.com> writes:
> On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
>
>> Hi,
>>
>> I am planning to work on issue 3690. Before starting with this I have
>> few questions.
>>
>> 1. Hyrum updated the issue with his comment stating that already there
>> is work going on in the branch ignore-mergeinfo which addresses
>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>> Rackover is talking about a new option passing which a user can
>> ignore revisions with just the following property changes alone.
>>
>> author eol-style externals keywords mime-type
>> date executable ignore log needs-lock
>
> Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
>
> Cheers,
> Daniel
> Sent from my phone.
>
I started working on this and I think I completed the changes for
svn_ra_local. Attached is the patch. This is a work in progress. I would
like to get some initial comments/suggestions on the patch and would
like to know whether I am proceeding on right direction.
This patch adds new option '--ignore-properties' to 'log' sub
command. If this option is provided then command ignore revisions that
has only property changes from output.
Thanks and Regards
Noorul
Re: Regarding issue 3690
Posted by Daniel Becroft <dj...@gmail.com>.
On 27/01/2011, at 17:04, Noorul Islam K M <no...@collab.net> wrote:
> Hi,
>
> I am planning to work on issue 3690. Before starting with this I have
> few questions.
>
> 1. Hyrum updated the issue with his comment stating that already there
> is work going on in the branch ignore-mergeinfo which addresses
> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
> svn:mergeinfo an svn property set using svn pset command? I think Zvi
> Rackover is talking about a new option passing which a user can
> ignore revisions with just the following property changes alone.
>
> author eol-style externals keywords mime-type
> date executable ignore log needs-lock
Fyi, svn:author, svn:date and svn:log are revision properties - changes to these don't appear in the log.
Cheers,
Daniel
Sent from my phone.
> 2. Zvi is talking about log command alone in the issue. I assume that we
> need this option only for log command.
>
> Any comments?
>
> Thanks and Regards
> Noorul
Re: Regarding issue 3690
Posted by Gavin Beau Baumanis <ga...@thespidernet.com>.
Good points Johan,
For those interested;
http://subversion.tigris.org/issues/show_bug.cgi?id=3690
Issue text;
Add an option to ignore files with only property changes and no content changes.
e.g. svn log --ignore-properties
Motivation: many users are not interested in reviewing changes to property changes
and only care about content changes.
------- Additional comments from Hyrum K. Wright Mon Jan 3 08:10:53 -0800 2011 -------
A subset of this problem (namely, ignoring changes to svn:mergeinfo) is being addressed on the ignore-
mergeinfo branch:
http://svn.apache.org/repos/asf/subversion/branches/ignore-mergeinfo/
Gavin "Beau" Baumanis
On 27/01/2011, at 7:40 PM, Johan Corveleyn wrote:
> On Thu, Jan 27, 2011 at 8:04 AM, Noorul Islam K M <no...@collab.net> wrote:
>> Hi,
>>
>> I am planning to work on issue 3690. Before starting with this I have
>> few questions.
>>
>> 1. Hyrum updated the issue with his comment stating that already there
>> is work going on in the branch ignore-mergeinfo which addresses
>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>> Rackover is talking about a new option passing which a user can
>> ignore revisions with just the following property changes alone.
>>
>> author eol-style externals keywords mime-type
>> date executable ignore log needs-lock
>>
>> 2. Zvi is talking about log command alone in the issue. I assume that we
>> need this option only for log command.
>
> Not replying to your questions, but a small remark on the side:
> whenever you mention an issue number, could you please also include
> the summary of the issue? Not everyone has these number memorized, so
> if people want to know what you're talking about, it takes time to
> look it up (especially if there is no link in the mail).
>
> Thanks,
> --
> Johan
Re: Regarding issue 3690
Posted by Noorul Islam K M <no...@collab.net>.
Johan Corveleyn <jc...@gmail.com> writes:
> On Thu, Jan 27, 2011 at 8:04 AM, Noorul Islam K M <no...@collab.net> wrote:
>
>> Hi,
>>
>> I am planning to work on issue 3690. Before starting with this I have
>> few questions.
>>
>> 1. Hyrum updated the issue with his comment stating that already there
>> is work going on in the branch ignore-mergeinfo which addresses
>> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
>> svn:mergeinfo an svn property set using svn pset command? I think Zvi
>> Rackover is talking about a new option passing which a user can
>> ignore revisions with just the following property changes alone.
>>
>> author eol-style externals keywords mime-type
>> date executable ignore log needs-lock
>>
>> 2. Zvi is talking about log command alone in the issue. I assume that we
>> need this option only for log command.
>
> Not replying to your questions, but a small remark on the side:
> whenever you mention an issue number, could you please also include
> the summary of the issue? Not everyone has these number memorized, so
> if people want to know what you're talking about, it takes time to
> look it up (especially if there is no link in the mail).
>
Here is the link
http://subversion.tigris.org/issues/show_bug.cgi?id=3690
and the following is the initial comment on the issue
Add an option to ignore files with only property changes and no content
changes. e.g. svn log --ignore-properties
Motivation: many users are not interested in reviewing changes to
property changes and only care about content changes.
Thanks and Regards
Noorul
Re: Regarding issue 3690
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jan 27, 2011 at 8:04 AM, Noorul Islam K M <no...@collab.net> wrote:
> Hi,
>
> I am planning to work on issue 3690. Before starting with this I have
> few questions.
>
> 1. Hyrum updated the issue with his comment stating that already there
> is work going on in the branch ignore-mergeinfo which addresses
> subset of issue 3690, i.e ignoring changes to svn:mergeinfo. Is
> svn:mergeinfo an svn property set using svn pset command? I think Zvi
> Rackover is talking about a new option passing which a user can
> ignore revisions with just the following property changes alone.
>
> author eol-style externals keywords mime-type
> date executable ignore log needs-lock
>
> 2. Zvi is talking about log command alone in the issue. I assume that we
> need this option only for log command.
Not replying to your questions, but a small remark on the side:
whenever you mention an issue number, could you please also include
the summary of the issue? Not everyone has these number memorized, so
if people want to know what you're talking about, it takes time to
look it up (especially if there is no link in the mail).
Thanks,
--
Johan