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

Re: [patch] Use hash for optional args with long argument list in Ruby bindings

From: Kouhei Sutou <kou_at_cozmixng.org>
Date: 2007-11-19 12:29:39 CET


In <ae6cb1100711181745n66d81168gfb6c3b1ca9888f1b@mail.gmail.com>
  "Re: [patch] Use hash for optional args with long argument list in Ruby bindings" on Sun, 18 Nov 2007 17:45:42 -0800,
  "Joe Swatosh" <joe.swatosh@gmail.com> wrote:

> Okay, I'm completely missing the boat here. I guess I'm still not convinced
> we need to support update_editor and switch_editor (the compatibility
> versions) since they have bugs. I'm starting to think I shouldn't have messed
> with this at all....

I think we don't need to keep the 1.4 API because the API
has bugs. This means nobody can't use the API with 1.4. So I
did break the API to fix the bugs in r24302. But now, I
think we should accept target_revision as optional argument
in update_editor API.

> Where we are now:
> A) update_editor2 and switch_editor2 are correct except that they have an
> unnecessary required argument (:target_revision) that should be an
> optional argument that your patch fixes for update_editor2.


> B) update_editor and switch_editor are copy-pasted from 1.4 bugs and all.
> r24302 which addressed the bugs on trunk also modified the calling
> interfaces so can't be directly applied to fix the bugs.

We don't need to keep 1.4 API. We should fix the bugs.

> Where we want to be(?):
> C) update_editor2 and switch editor2 need to have :target_revision moved
> from required to optional and apply the revnum defaulting logic to
> svn_wc.i (as the patch)


> D) update_editor and switch_editor fix the bugs, but leave the calling
> interface the same.

We should add optional target_revision argument.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 19 12:30:02 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.