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

Re: [PATCH] Ruby bindings client for merge_peg

From: Kouhei Sutou <kou_at_cozmixng.org>
Date: 2007-08-17 13:49:19 CEST

Hi,

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

Me too...
I hope someone helps us.

For now, could you use rev2 as default? If someone helps us,
we may change default value or require a value.

Thanks,

--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 17 13:47:10 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.