Greg Stein <gstein@lyra.org> writes:
> On Wed, Apr 03, 2002 at 02:49:50PM -0600, sussman@tigris.org wrote:
> >...
> > Stop using the trace-commit editor in a half-XXXed way. Instead, send
> > detailed feedback to the application that *looks* like the old
> > trace-commit editor output. This should cause our python tests to
> > pass again with the new commit system.
>
> "should" or "do" ? :-)
>
> I presume this was coordinated with Mike?
Yah, it's the plan that I came up with this morning, but Ben wanted to
implement it. And implement it, he did! Whoo!!
> Is it reasonable now to remove the before/after editor concept [from across
> the interface] ? i.e. stop composing editors and shift to a pure
> notification system?
I'd certainly like to do so.
My Big Issue with the whole before/after editor thing boils down to
one thing. If you take a look at the interfaces for
svn_client_update, _import, _switch, _commit, etc. you'll note that
nowhere in the docstrings is it mentioned (or even strongly implied)
that the underlying implementation of those actions involves the use
of editors. Sure, we know that under the hood they use editors, but
the minute that changes, or the minute that editors are used
differently than expected (like in the new commit system) those
before/after editors either a) have nothing to be composed with at
all, or b) just don't work.
In my opinion, the use of editors for the client-layer operations is
an implementation detail that need not be exposed outside that layer.
> This sequence of else/if makes it look like the "state_flags" should
> actually be an enumerated constant, rather than bit fields.
Nonono. These are non-exclusive. For example, something copied and
modified can have a state with ADD, COPIED, and TEXT_MODS set.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 4 00:52:40 2002