Wed, 12 Feb 2014 10:16:21 -0800 revset: added spanset class to represent revision ranges
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 12 Feb 2014 10:16:21 -0800] rev 20482
revset: added spanset class to represent revision ranges
Thu, 06 Feb 2014 08:36:11 -0800 revset: added lazyset implementation to extra revset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 08:36:11 -0800] rev 20481
revset: added lazyset implementation to extra revset
Thu, 06 Feb 2014 08:32:40 -0800 revset: added lazyset implementation to converted revset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 08:32:40 -0800] rev 20480
revset: added lazyset implementation to converted revset
Thu, 06 Feb 2014 08:31:55 -0800 revset: added lazyset implementation to closed revset
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 06 Feb 2014 08:31:55 -0800] rev 20479
revset: added lazyset implementation to closed revset
Fri, 31 Jan 2014 01:12:35 -0800 push: feed pulloperation object to _pullobsolete function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 31 Jan 2014 01:12:35 -0800] rev 20478
push: feed pulloperation object to _pullobsolete function We now have all necessary information in the `pulloperation` object itself.
Fri, 31 Jan 2014 01:04:05 -0800 pull: move transaction logic into the pull object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 31 Jan 2014 01:04:05 -0800] rev 20477
pull: move transaction logic into the pull object Most local change that occurs during a pull are doing within a `transaction`. Currently this mean (1) adding new changeset (2) adding obsolescence markers. We want the two operations to be done in the same transaction. However we do not want to create a transaction if nothing is added to the repo. Creating an empty transaction would drop the previous transaction data and confuse tool and people who are still using rollback. So the current pull code has some logic to create and handle this transaction on demand. We are moving this logic in to the `pulloperation` object itself to simplify this lazy creation logic through all different par of the push. Note that, in the future, other part of pull (phases, bookmark) will probably want to be part of the transaction too.
Thu, 30 Jan 2014 17:38:41 -0800 pull: move obsolescence marker exchange in the exchange module
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:38:41 -0800] rev 20476
pull: move obsolescence marker exchange in the exchange module The obsolescence marker exchange code was already extracted during a previous cycle. We are moving the extracted functio in this module. This function will read and write data in the `pulloperation` object and I prefer to have all core function collaborating through this object in the same place. This changeset is pure code movement only. Code change for direct consumption of the `pulloperation` object will come later.
Sat, 01 Feb 2014 03:49:29 -0800 pull: move `force` argument into pull object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 01 Feb 2014 03:49:29 -0800] rev 20475
pull: move `force` argument into pull object One more step toward a more modular pulh function.
Thu, 30 Jan 2014 17:35:55 -0800 pull: move `heads` argument into pull object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:35:55 -0800] rev 20474
pull: move `heads` argument into pull object One more step toward a more modular pull function.
Thu, 30 Jan 2014 17:32:04 -0800 pull: move `remote` argument into pull object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:32:04 -0800] rev 20473
pull: move `remote` argument into pull object One more step toward a more modular pull function.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip