Wed, 16 Jan 2013 20:41:34 +0100 bundlerepo: improve performance for bundle() revset expression
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:34 +0100] rev 18411
bundlerepo: improve performance for bundle() revset expression Create the set of revision numbers directly instead of creating a list of nodes first.
Wed, 16 Jan 2013 20:41:32 +0100 bundlerepo: fix outdated comment
Mads Kiilerich <madski@unity3d.com> [Wed, 16 Jan 2013 20:41:32 +0100] rev 18410
bundlerepo: fix outdated comment Comment was made invalid by 01ee43dda681.
Wed, 16 Jan 2013 13:18:22 +0100 hgweb: pass repo object to revnav construction
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 13:18:22 +0100] rev 18409
hgweb: pass repo object to revnav construction For compatibility with changelog filtering we need access to the changelog, a simple nodefunc is not sufficient, only the changelog and repo have access the filteredrevs information. For the filerevnav version, we use an unfiltered changelog. Linkrev is currently broken with filtering and we need some failsafe to prevent traceback. This is the same approach as the one used in 518c1403838f. The use of filectx.changectx() allowed the previous code to use the 518c1403838f hack. This changeset may result in an incorrect behaviors, Navigation link may point to missing revision. However this bad navigation generation is much better than a plain crash
Mon, 14 Jan 2013 16:55:48 +0100 hgweb: introduction a filerevnav subclass
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 14 Jan 2013 16:55:48 +0100] rev 18408
hgweb: introduction a filerevnav subclass It'll be use to implement the file specific behavior.
Thu, 10 Jan 2013 19:09:32 +0100 hgweb: simplify addition of "(0) navigation entry"
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 19:09:32 +0100] rev 18407
hgweb: simplify addition of "(0) navigation entry"
Mon, 14 Jan 2013 16:30:06 +0100 hgweb: simplify the handling of empty repo
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 14 Jan 2013 16:30:06 +0100] rev 18406
hgweb: simplify the handling of empty repo This abstraction have two advantages: - If the revlog is empty, None of the code bellow is relevant, early returns seems a win. - Abtraction of the 'emptiness' check will help later when we stop relying on nodefunc. A bonus, with filtering, a non-empty revlog may not have '0' revision accessible. It'll be easier to handle with the emptiness test in a dedicated function
Thu, 10 Jan 2013 18:54:50 +0100 hgweb: move hex creation into an object method
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:54:50 +0100] rev 18405
hgweb: move hex creation into an object method This is clearer and allow later overwrite.
Thu, 10 Jan 2013 18:59:37 +0100 hgweb: pass nodefunc to the revnav object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 10 Jan 2013 18:59:37 +0100] rev 18404
hgweb: pass nodefunc to the revnav object The issue between hgweb and filtering lay in this function. Moving it into the object itself helps to abstract the erroneous bit.
Tue, 15 Jan 2013 21:17:18 +0100 hgweb: move revnavgen into an object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 15 Jan 2013 21:17:18 +0100] rev 18403
hgweb: move revnavgen into an object For later compatibility with changelog filtering some part of the navigation generation logic will be altered. Those altered part will be different when in the changelog case and in the filelog case. Moving this into an object will allow to use inheritance to override just the part of the logic we need. The aimed logic are for example: - generation of revision 'hex' (different logic for changelog and filelog) - revlog emptyness test - fetching of the first revision of a revlog (may not be 0)
Wed, 16 Jan 2013 12:51:24 +0100 hgweb: `limit` argument is actually `latestonly` renames and enforce
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 12:51:24 +0100] rev 18402
hgweb: `limit` argument is actually `latestonly` renames and enforce The `limit` argument of several generator have only two possible values in practice: 0 and 1. We rename this parameter to `latestonly` and simplify it's handling. The simplification allows us to save fetching of data that we are sure to not consume. Having a function minimal function perimeter will helps future refactoring.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip