Gerco Ballintijn writes:
> Yes, as I realize now there are three ways to go: (1) Provide the revision
> properties as part of the get_commit_editor() call, what I did in my patch;
> (2) Provide the revision properties through a new change_file_prop() "method"
> in the svn_delta_editor_t struct; or (3) Provide the revision properties as
> part of the close_edit() method of the svn_delta_editor_t struct. Method (1)
> and (3) seem to have the least impact on the existing code, but method (2)
> is the cleanest and most generic. (Method (2) and (3) both allow the revision
> properties to be provided at the end).
Unfortunately, the editor is not documented to be extensible, so
approaches 2 and 3 will require revising that struct, which will be a lot
of work. If someone wants to take that (whictch we will need to do at
some point for other things), that'd be great, but I'm not sure I think
this feature need to block on that, especially since it can be useful
without the ideal genericity.
> >> A separate issue was (is) whether to ignore, to filter, or to flag the
> >> standard revision properties as errors when passed in the table.
> > I think it would make sense to disallow any changes to the svn:
> > properties, since they're already set through other processes (and you
> > wouldn't want, for example, to have to work out whether someone could
> > override svn:author).
> But would such a prohibition be for the command-line client *only* or
> for all (relevant) public APIs?
To make sense, this has to be prohibited on the server side.
> > I also wondered whether we should be calling the pre- and post-
> > revprop-change hooks, or whether we just leave it to the pre-commit
> > hook.
> The notes in the bugtracker seem to suggest that since this new functionality
> is not about changes historic data, but about creating new historic data, no
> call to the revprop-change hooks is needed. This seems to me a reasonable
I agree. I don't think the change revprop hooks should be called.
The pre-commit hooks can do necessary checking.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Feb 20 16:20:08 2007