[Bug 3628 - single transaction for graft with multiple revisions]

[Piotr Listkiewicz]

>
> So it is in fact a hard bug and will require
> understanding the whole transaction mechanism and figuring out how to
> extend it. I probably wouldn't work on this one.


So it's definetely not a bug for me now, thanks for reply

2015-09-29 23:31 GMT+02:00 Matt Mackall <mpm at selenic.com>:

> On Tue, 2015-09-29 at 20:38 +0200, Piotr Listkiewicz wrote:
> > Up ,maybe anybody can help with this?
>
> You probably shouldn't try to imitate the BTS robot's subject lines
> because people like to ignore it.
>
> > 2015-09-22 20:57 GMT+02:00 Piotr Listkiewicz <
> piotr.listkiewicz at gmail.com>:
> >
> > > I took a look at issue: http://bz.selenic.com/show_bug.cgi?id=3628 . I
> > > started working on it, i hoped that sth like:
> > >
> > > diff -r 836291420d53 -r 0861313845a8 mercurial/commands.py
> > > --- a/mercurial/commands.py     Sat Sep 12 16:11:17 2015 -0700
> > > +++ b/mercurial/commands.py     Tue Sep 22 20:47:36 2015 +0200
> > > @@ -3578,8 +3578,11 @@
> > >          if not revs:
> > >              return -1
> > >
> > > -    wlock = repo.wlock()
> > >      try:
> > > +        wlock = repo.wlock()
> > > +        lock = repo.lock()
> > > +        tr = repo.transaction("graft")
> > > +
> > >          for pos, ctx in enumerate(repo.set("%ld", revs)):
> > >              desc = '%d:%s "%s"' % (ctx.rev(), ctx,
> > >                                     ctx.description().split('\n',
> 1)[0])
> > > @@ -3636,8 +3639,10 @@
> > >                  ui.warn(
> > >                      _('note: graft of %d:%s created no changes to
> > > commit\n') %
> > >                      (ctx.rev(), ctx))
> > > +
> > > +        tr.close()
> > >      finally:
> > > -        wlock.release()
> > > +        release(tr, lock, wlock)
> > >
> > > would work but its not. Problem with making graft transactional in
> such a
> > > way is encountered when there are conflicts during merge - transaction
> is
> > > rolled back before it gives a user chance to resolve merge commit.
>
> The above is the sort of fix whoever marked it easy in the BTS (me?)
> probably had in mind. But they probably hadn't considered the case of
> transactions spanning multiple command executions (that don't exist
> anywhere else in hg). So it is in fact a hard bug and will require
> understanding the whole transaction mechanism and figuring out how to
> extend it. I probably wouldn't work on this one.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150930/a515c2f6/attachment.html>