Wed, 26 Dec 2012 11:16:18 -0600 merge with stable
Kevin Bullock <kbullock@ringworld.org> [Wed, 26 Dec 2012 11:16:18 -0600] rev 18133
merge with stable
Mon, 24 Dec 2012 02:49:59 +0100 branchmap: move validity logic in the object itself
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 24 Dec 2012 02:49:59 +0100] rev 18132
branchmap: move validity logic in the object itself In several place, We check if a branchcache is still valid regarding the current state of the repository. This changeset puts this logic in a method of the object that can be reused when necessary. A branch map is considered valid whenever it is up to date or a strict subset of the repository state. The change will help making branchcache aware of filtered revision. The change in keyword is expected. the branch cache is actually invalid after the amend. The previous check did not detected it.
Sat, 22 Dec 2012 17:08:15 +0100 branchmap: make update a method
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 22 Dec 2012 17:08:15 +0100] rev 18131
branchmap: make update a method
Mon, 24 Dec 2012 02:22:04 +0100 branchmap: make update responsible to update the cache key
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 24 Dec 2012 02:22:04 +0100] rev 18130
branchmap: make update responsible to update the cache key The update function have all necessary data to keep the branchcache key up to date with its value. This saves assignment to the cache key that each caller of update had to do by hand. The strip case is a bit more complicated to handles from inside the function but I do not expect any impact.
Sat, 22 Dec 2012 02:11:12 +0100 branchmap: factorise changelog access in update
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 02:11:12 +0100] rev 18129
branchmap: factorise changelog access in update This both improves readability and performance. Access to changelog of filtered repository currently have a minor overhead.
Thu, 20 Dec 2012 16:28:43 +0100 branchmap: make write a method on the branchmap object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 16:28:43 +0100] rev 18128
branchmap: make write a method on the branchmap object
Sat, 22 Dec 2012 02:04:49 +0100 branchmap: simplify write signature
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 02:04:49 +0100] rev 18127
branchmap: simplify write signature All necessary data (cache value and key) are now stored in the branchcache object. Any extra parameter is superfluous.
Sat, 22 Dec 2012 02:06:26 +0100 branchmap: add the tiprev (cache key) on the branchmap object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 02:06:26 +0100] rev 18126
branchmap: add the tiprev (cache key) on the branchmap object The actual cache key used on disk is the (tipnode, tiprev) pair. There is no reason not to use the revision number for the in memory version.
Sat, 22 Dec 2012 01:59:05 +0100 branchmap: add the tipnode (cache key) on the branchcache object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 01:59:05 +0100] rev 18125
branchmap: add the tipnode (cache key) on the branchcache object Gathering data and cache key paves the way to a lot of simplification.
Sat, 22 Dec 2012 01:44:42 +0100 branchmap: store branchcache in a dedicated object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 01:44:42 +0100] rev 18124
branchmap: store branchcache in a dedicated object Value and key of branchcache would benefit from being hold by the same object. Moreover some logic (update, write, validation) could be move on such object. The creation of this object is the first step toward this move. The result will clarify branchcache related code and hide most of the detail in the class itself. This encapsulation will greatly helps implementation of branchcache for filtered view of the repo.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip