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.
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.
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.
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.
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.
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.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 17:24:49 -0800] rev 20472
pull: introduce a pulloperation object
This object will hold all data and state gathered through the pull. This will
allow us to split the long function into multiple small one. Smaller function
will be easier to maintains and wrap. The idea is to blindly store all
information related to the pull in this object so that each step and extension
can use them if necessary.
We start by putting the `repo` variable in the object. More migration in other
function.
Simon Heimberg <simohe@besonet.ch> [Mon, 27 Jan 2014 21:39:25 +0100] rev 20471
tests: lines with largefile .* file://$TESTTMP also match on windows
on windows, largefile paths are written as "file:///C:/temp/...", corresponding
to "file:///$TESTTMP/..." (all three slashes shown).
But on posix systems they are written as "file:///tmp/..." corresponding to
"file://$TESTTMP/..." (only two slashes shown).
Write the glob "file:/*/" to match both versions.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 11 Feb 2014 16:30:23 -0800] rev 20470
debugobsolete: extract marker display in a dedicated function
We want to be able to reuse and extend it from other function or
extension while working on markers exchange.
This changeset is pure core movement.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 30 Jan 2014 16:12:49 -0800] rev 20469
exchange: extract pull function from localrepo
The localrepo class if far too big. Push and pull logic are extracted and
reworked to better fit with the fact we exchange more than bundle now.
This changeset extract the pulh code. later changeset will slowly slice it into
smaller brick.
The localrepo.pull method is kept for now to limit impact on user code. But it
will be ultimately removed, now that the public API is hold by peer.