Fri, 17 Aug 2012 13:58:18 -0700 spelling: nonexistent
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17492
spelling: nonexistent
Fri, 17 Aug 2012 13:58:18 -0700 spelling: existence
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17491
spelling: existence
Fri, 17 Aug 2012 13:58:18 -0700 spelling: exercise
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17490
spelling: exercise
Fri, 17 Aug 2012 13:58:18 -0700 spelling: equivalent
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17489
spelling: equivalent
Fri, 17 Aug 2012 13:58:18 -0700 spelling: efficiently
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17488
spelling: efficiently
Fri, 17 Aug 2012 13:58:18 -0700 spelling: don't/do not
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17487
spelling: don't/do not
Fri, 17 Aug 2012 13:58:18 -0700 spelling: doesn't/does not
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17486
spelling: doesn't/does not
Fri, 17 Aug 2012 13:58:18 -0700 spelling: destination
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17485
spelling: destination
Fri, 17 Aug 2012 13:58:18 -0700 spelling: directly
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17484
spelling: directly
Fri, 17 Aug 2012 13:58:18 -0700 spelling: descendants
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17483
spelling: descendants
Fri, 17 Aug 2012 13:58:18 -0700 spelling: deactivate
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17482
spelling: deactivate
Fri, 17 Aug 2012 13:58:18 -0700 spelling: dependent
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17481
spelling: dependent
Fri, 17 Aug 2012 13:58:18 -0700 spelling: Failing
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17480
spelling: Failing
Fri, 17 Aug 2012 13:58:18 -0700 spelling: Explicitly
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17479
spelling: Explicitly
Fri, 17 Aug 2012 13:58:18 -0700 spelling: Environment
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17478
spelling: Environment
Fri, 17 Aug 2012 13:58:18 -0700 spelling: Construct
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17477
spelling: Construct
Fri, 17 Aug 2012 13:58:18 -0700 spelling: Authoritative
timeless@mozdev.org [Fri, 17 Aug 2012 13:58:18 -0700] rev 17476
spelling: Authoritative
Tue, 11 Sep 2012 00:12:07 +0200 amend: add obsolete support
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 11 Sep 2012 00:12:07 +0200] rev 17475
amend: add obsolete support If the obsolete feature is enabled, `hg commit --amend` marks a changeset as obsolete instead of stripping it.
Fri, 24 Aug 2012 21:16:23 +0200 obsolete: add a high level function to create an obsolete marker
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 24 Aug 2012 21:16:23 +0200] rev 17474
obsolete: add a high level function to create an obsolete marker This function is designed to be used by all code that creates new obsolete markers in the local repository. It is not used by debugobsolete because debugobsolete allows the use of an unknown hash as argument.
Sat, 25 Aug 2012 16:20:41 +0200 amend: use an explicit commit message for temporary amending commit
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 25 Aug 2012 16:20:41 +0200] rev 17473
amend: use an explicit commit message for temporary amending commit Before this changeset, the extra commit created during amend had the same description as the final commit. This was a bit confusing when trying to understand what that extra commit was about. This changeset changes the description of such commit to: temporary amend commit for <ammend-commit-hash> The old behaviour was not a big deal, but would become more confusing once we use obsolescence marker instead of stripping the precursors. This also helps if the user restores a strip backup.
Mon, 10 Sep 2012 23:44:24 +0200 amend: wrap all commit operations in a single transaction
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Sep 2012 23:44:24 +0200] rev 17472
amend: wrap all commit operations in a single transaction This allows proper recovery of an interrupted amend process. No changes are made to the logic besides: - indent operations into a single try-except clause, - some comment and code wrapping to 80 chars, - strip logic should not be contained in the transaction and is extracted from the main code.
Sat, 25 Aug 2012 15:37:28 +0200 amend: lock the repository during the whole process
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Aug 2012 15:37:28 +0200] rev 17471
amend: lock the repository during the whole process Without this changes another writer can lock the repository in the middle the amend process. The resulting mess can be pretty ugly.
Mon, 10 Sep 2012 14:08:10 -0700 Merge with crew
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Sep 2012 14:08:10 -0700] rev 17470
Merge with crew
Tue, 28 Aug 2012 20:52:04 +0200 obsolete: introduce caches for all meaningful sets
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 28 Aug 2012 20:52:04 +0200] rev 17469
obsolete: introduce caches for all meaningful sets This changeset introduces caches on the `obsstore` that keeps track of sets of revisions meaningful for obsolescence related logics. For now they are: - obsolete: changesets used as precursors (and not public), - extinct: obsolete changesets with osbolete descendants only, - unstable: non obsolete changesets with obsolete ancestors. The cache is accessed using the `getobscache(repo, '<set-name>')` function which builds the cache on demand. The `clearobscaches(repo)` function takes care of clearing the caches if any. Caches are cleared when one of these events happens: - a new marker is added, - a new changeset is added, - some changesets are made public, - some public changesets are demoted to draft or secret. Declaration of more sets is made easy because we will have to handle at least two other "troubles" (latecomer and conflicting). Caches are now used by revset and changectx. It is usually not much more expensive to compute the whole set than to check the property of a few elements. The performance boost is welcome in case we apply obsolescence logic on a lot of revisions. This makes the feature usable!
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 +30000 tip