On Fri, 17 Aug 2007, Kouhei Sutou wrote:
> > > > > 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.
How about following the same algorithm for defaulting the peg revision
as in subversion/svn/merge-cmd.c?
If a peg revision is unspecified, it's defaulted to HEAD for URLs, and
WORKING for WC paths.
Received on Fri Aug 17 20:21:50 2007
- application/pgp-signature attachment: stored