[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 1623 - trunk/subversion/include trunk/subversion/libsvn_client trunk/subversion/clients/cmdline

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-04-04 01:30:47 CEST

Cool. Thanks for this one, re: editors. I was busy venting on comments :-)
before getting to Ben's reply to my query about the editors. I think you
articulated it a lot better than I would have

On Wed, Apr 03, 2002 at 04:50:52PM -0600, cmpilato@collab.net wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > 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.

Yes! "Coupling" would be the word here. The exposure of the editors couples
the inside pieces to the outside pieces. And due to the nature of the editor
interface, it does it very strongly.

> In my opinion, the use of editors for the client-layer operations is
> an implementation detail that need not be exposed outside that layer.

Agreed. I think you really clarified the gut issue that I had with them.

> > 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.

Hmm. Well, that section of code is a bunch of else/ifs. You may want to
review the sequence to ensure that all combos are properly represented.
There is potential for error in there, especially if more flags are grown or
combos available.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 4 01:26:52 2002

This is an archived mail posted to the Subversion Dev mailing list.