Gerco Ballintijn writes:
> Peter Lundblad wrote:
> > You can read more about our compatibility rules in the hacking
> > document.
> I did read it (several times actually). The crux is the correct and
> *complete* application of the ideas. :-)
I understand. Just wanted to make sure you knew where it was;)
> I am correct in thinking that *it is solvable* by copying the user
> provided editor structure, and extending it with a dummy set_edit_prop
> function, as in the following. Right?
It is definitely solvable. Making a wrapper editor is another way of
solving it. The only way I can think of where it matters is if a user
modifies the editor structure during the edit. The internal copy
wouldn't reflect such changes. This is contrived, I admit.
OTOH, we traditionally created wrappers in these cases.
IN any case, please make the function that gets you a compatibility editor
> A quick scan of the subversion include directory reveals the
> following affected functions, function-pointers, and structure.
> svn_ra_plugin_t (because of previous five)
> svn_ra_get_ra_library (because of previous)
Don't touch, this is compatibility crap, meaning that you don't need
> >> My intention was always to discuss and, if needed, create a v2 editor
> >> structure. I don't think its that much work. I'm not sure what you mean
> >> with a separate patch though...
> > I mean that this patch is getting big if you revise the editor as well and
> > therefore gets hard to review. A nice way of splitting it would be to revise
> > the editor in one patch and do the rest in another. The former patch is
> > useful even if the an incarnation of set_edit_or_txn_or_rev_..._prop is
> > not added.
> I'm not sure what the purpose would be of the part without the method
> set_edit_prop. What (generic) aspect of the editor would be revised?
> (and in what way?)
Making it extensible in the future. We already have an instance that
would need it (see the new editor in
(And problems with getting big patches reviewed and committed is real;)
> I was thinking along the lines of properties specifing the number of lines
> changed in plain text files, the number of changed files in general, or
> some other commit or change statistic; a language-specific client that
> stores the names of the changed functions, classes, etc.; or a performance
> tracking client that stores commit durations in the server for later
> aggragation. Something like that, nothing particularly worked out.
OK, none of these are convincing to me. Statistics can be calculated in
advance or handled by a pre-commit hook on the server.
The performance thing is a bit contrived IMO. *I know these were just
ad hoc thoughts).
I stand with my opinion that arbitrary metadata that's available when
the commit starts (bug id, reviewer, possibly others) is the main use case we
should care about.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Mar 2 08:11:10 2007