Wed, 17 Aug 2022 10:17:15 -0400 shelve: in test for trailing whitespace, strip commit (issue6735)
Jason R. Coombs <jaraco@jaraco.com> [Wed, 17 Aug 2022 10:17:15 -0400] rev 49454
shelve: in test for trailing whitespace, strip commit (issue6735)
Mon, 15 Aug 2022 10:26:01 -0400 shelve: demonstrate that the state is different across platforms (issue6735)
Jason R. Coombs <jaraco@jaraco.com> [Mon, 15 Aug 2022 10:26:01 -0400] rev 49453
shelve: demonstrate that the state is different across platforms (issue6735)
Tue, 16 Aug 2022 20:09:31 +0200 phase: rename the requirement for internal-phase (BC)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 20:09:31 +0200] rev 49452
phase: rename the requirement for internal-phase (BC) The previous requirements covers both `internal` and `archived` phase. However, the `archived` phase is not ready for usage (while the internal one is mostly ready for years). So we split the archived on in a dedicated requirements (see previous changeset for details) and rename the one for internal-phase. This will avoid older client trying to use the archived phase on `internal` only repositories. Since the requirements stayed experimental since its introduction. It seems fine to drop the previous version.
Tue, 16 Aug 2022 19:04:23 +0200 phase: introduce a dedicated requirement for the `archived` phase
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 19:04:23 +0200] rev 49451
phase: introduce a dedicated requirement for the `archived` phase See inline documentation for details.
Tue, 16 Aug 2022 18:20:42 +0200 phase: introduce a dedicated function to check for the archived phase
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 18:20:42 +0200] rev 49450
phase: introduce a dedicated function to check for the archived phase The internal-phase is "ready to use" since its introduce. However, some question remains around the `archived` phase. So it seem safer to move them to separated configuration and requirements. This changeset is a first of a small series doing this.
Wed, 20 Apr 2022 19:24:39 +0200 rebase: add boolean config item rebase.store-source
C. Masloch <pushbx@ulukai.org> [Wed, 20 Apr 2022 19:24:39 +0200] rev 49449
rebase: add boolean config item rebase.store-source This allows to use rebase without recording a rebase_source extra field. This is useful for example to build a mirror converted from another SCM (such as svn) by converting only new revisions, and then incrementally add them to the destination by pulling from the newly converted (unrelated) repo and rebasing the new revisions onto the last old already stored changeset. Without this patch the rebased changesets would always receive some rebase_source that would depend on the particular history of the conversion process, instead of only depending on the original source revisions. This is used to implement a hg mirror repo of SvarDOS (a partially nonfree but completely redistributable DOS distribution) in the scripts at https://hg.pushbx.org/ecm/svardos.scr/ In particular, cre.sh creates an svn mirror, upd.sh recreates an entire hg repo from the svn mirror (which takes too long to do in a regular job), and akt.sh uses hg convert with the config item convert.svn.startrev to incrementally convert only the two most recent revisions already found in the mirror destination plus any possible new revisions. If any are found, the temporary repo's changesets are pulled into the destination (as changesets from an unrelated repository). Then the changesets corresponding to the new revisions are rebased onto the prior final changeset. (Finally, the two remaining duplicates of the prior head and its parent are stripped from the destination repository.) Without this patch, the particular rebase_source extra field would depend on the order and times at which akt.sh was used, instead of only depending on the source repository. In other words, whatever sequence of upd.sh and akt.sh is used at whatever times, it is desired that the final output repositories always match each other exactly.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 tip