Re: [PATCH] Ruby bindings client for merge_peg

Hi kou

On 8/15/07, Kouhei Sutou <kou@cozmixng.org> wrote:
> Hi,
>
> In <ae6cb1100708140743p4d574513md269776b33f95847@mail.gmail.com>
> "Re: [PATCH] Ruby bindings client for merge_peg" on Tue, 14 Aug 2007 07:43:08 -0700,
> "Joe Swatosh" <joe.swatosh@gmail.com> wrote:
>
> > > Uhm... What about the following:
> > >
> > > def merge_peg(src, rev1, rev2, target_wcpath,
> > > peg_rev=nil, depth=nil, ...)
> > > peg_rev ||= rev2
> > > ...
> > >
> >
> > I thought about that. To be honest I don't understand peg revisions
> > that well, but
> > it seemed like a method called merge_peg might reasonably require a peg revision
> > argument. So if this is a better solution we should just use it instead.....
>
> If there is a reasonable default value, I don't want to
> require the value. In this case, you always use rev2 as
> peg_rev. So it seems that rev2 is a reasonable default
> value. Is it not right?
>

Your argument seems correct to me, but I don't know about the
conclusion. I used rev2 because that made merge_peg behave the way
the tests were expecting (looks basically like merge to me).

I guess the reason I'm hesitating is I'm not sure what the difference
between a merge and a merge_peg is if peg_rev==rev2. The other thing
is the C code makes sure this is not null, if it were reasonable to
have peg_rev assigned to rev2 it could have been done there.

I've never used merge_peg myself, if you've actually used it and this
was a good default let's just make it the default. On the other hand,
is there someone we can drag into this conversation to be an expert?

Thanks,

--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org