Hi,
David Glasser wrote:
> On 2/24/07, Peter Lundblad <plundblad@google.com> wrote:
>> Also, while thinking of this, I'm not sure that this commit-specific
>> function belongs in the general editor interface. An alternative is
>> to have svn_ra_get_commit_editor() return a callback/baton that can be
>> used for this purpose. We should restrict the use of this callback to
>> either before any editing operations to simplify the implementation.
>> I admit that this is not entirely unugly either. Better suggestions
>> welcome.
>
> I posted a partial (no DAV, I think) patch towards an implementation
> that works this way last year. People didn't seem to think that was
> the best way to do it at the time, though I forget exactly why.
>
> http://svn.haxx.se/dev/archive-2006-08/0351.shtml
>
After having read this thread, I think there was no clear consensus
either way. The various options seem to have been discussed then as
well: pass revprops as part of get_editor call, as a separate function
using the edit baton, and as a method in the editor structure. For
me there were two main points in the thread. The first point was to
call the method (in the method variant) change_edit_prop instead of
change_rev_prop to disconnect it from commits and revisions. If you
follow the idea of the dir/file props, where every property can be
changed *only once*, it makes however more sense to prohibit NULL values
(since no deletes are possible then) and call the method set_edit_prop().
The second point was some insistence on making the method return an error
in the default implementation (instead of being a no-op). This seems a
good idea, a delta producer should only call methods that are explicitly
filled in by its delta consumer. However, I think this idea also applies
to all the other places in the code where the editor structure is only
partially filled in. If a consumer wants to consume a delta by doing
nothing it should explicitly assign a no-op function to that field, but
that is probably a different discussion.
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 28 21:47:32 2007