[PATCH 1 of 4] bookmarks: use recordchange instead of writing if transaction is active

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Mon Oct 5 09:42:00 CDT 2015


At Sun, 04 Oct 2015 16:01:27 -0700,
Pierre-Yves David wrote:
> 
> 
> On 10/04/2015 05:44 AM, FUJIWARA Katsunori wrote:
> > # HG changeset patch
> > # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> > # Date 1443962009 -32400
> > #      Sun Oct 04 21:33:29 2015 +0900
> > # Node ID 1655b19c19bdd94da85d568c1da65b09de4b402d
> > # Parent  97dc6ab42aad232c73180dee648685c26662230b
> > bookmarks: use recordchange instead of writing if transaction is active
> 
> I was initially not very enthousiastic about this patch because I would 
> like bookmark.write to just die and all bookmarks move to be done in the 
> transaction. And I would like code touching bookmark to have to 
> explicitly pass a transaction object so that they have to think about 
> the transaction life time when doing so.

BTW, would you plan to put updating bookmark via "hg update" into a
transaction scope, too ?


FYI, 'bmstore.write()' are invoked also from functions below, and
these may not be inside transaction at runtime, AFAIK:

- histedit.movebookmarks
  at the end of histedit-ing (via _histedit)

- mq.queue.refresh
  at the end of refreshing for qrefresh/qfold

- rebase.rebase
  at the end of rebasing (mainly focused by this patch)

- repair.repair
- strip
  - strip
  - stripcmd

  refactoring bookmark operations between them may be able to put
  bookmark updating into a transaction scope in 'repair.repair'.


> However this seems like a step forward in all cases so I'll probably 
> take that patch anyway.

To implement "transactional dirstate" at first, I'll post this patch
as it is also in V2 series (but with some additional comment), because
discarding 'bmstore.write()' needs some more complicated working as
described above.

> -- 
> Pierre-Yves David
> 

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp


More information about the Mercurial-devel mailing list