Obsolete markers wide-usage and propagation should be avoided by default until
the obsolete feature is more mature.
This changeset introduce the `_enable` variable and prevent the creation of
obsolete marker if the feature is set to `False` (the default).
More limitation comes in followup changesets.
This change adds `obsstore` to the list of files copied by local clone,
until now changesets were copied without their obsolete markers.
Note: extinct changesets were and are still included by such clones to
enable hardlinking. There is no obvious reason to prevent their exchange
here.
Rebased by Patrick Mezard <patrick@mezard.eu>
If we push some successors they will likely create a new head on
remote. However as the obsoleted head will disappear after the push we
are not really increasing the number of heads.
There is several case which will lead to extra being actually pushed. But this
first changeset aims to be simple. See the inline comment for details.
Without this change, you need to push --force every time you want to
push a newer version which is very error prone.
The remote side still display +n heads on unbundle because it does not have the
obsolete marker at unbundle time.
The repo.hiddenrevs set is updated with all extinct() changesets which aren't
descendants of either:
- the current working copy,
- a bookmark,
- a tag.
Extinct changesets are excluded from all exchange operations. This is a silent
exclusion because the user should not need to be aware of them.
There is no reason to strongly enforce this exclusion except implementation
simplicity. User should be able to explicitly request an extinct changeset in
the future.
`extinct` changesets are obsolete changesets with obsolete descendants only. They
are of no interest anymore and can be:
- exclude from exchange
- hidden to the user in most situation
- safely garbage collected
This changeset just allows mercurial to detect them.
The implementation is a bit naive, as for unstable changesets. We better use a
simple revset query and a cache, but simple version comes first.
User should resolve unstability locally before pushing the same way we encourage
user to merge locally instead of pushing a new remote head.
If we are to push obsolete changeset, at least one set of the pushed set will be
either obsolete or unstable. The check is narrowed to only heads.
An unstable changeset is a changeset *not* obsolete but with some obsolete
ancestors.
The current logic to decide if a changeset is unstable is naive and very
inefficient. A better solution is to compute the set of unstable changeset with
a simple revset and to cache the result. But this require cache invalidation
logic. Simpler version goes first.
Marker are now written as soon as possible but within a transaction. Using a
transaction ensure a proper behavior on error and rollback compatibility.
Flush logic are not necessary anymore and are dropped from lock release.
With this changeset, the obsstore is open, written and closed for every single
added marker. This is expected to be highly inefficient and batched write should
be implemented "quickly".
Another issue is that every flush of the file will invalidate the obsstore
filecache and trigger a full re instantiation of the repo.obsstore attribute
(including, reading and parsing entry). This is also expected to be highly
inefficient and proper filecache operation should be implemented "quickly" too.
A side benefit of the filecache issue is that repo.obsstore object is properly
invalidated on transaction abortion.
Changeset detected as obsolete will be displayed as "x" instead of 'o':
o new rewritten changeset
|
| x old obsolete changeset
|/
|
o base
This will be useful even when some obsolete changeset will be "hidden" because
not all obsolete changeset can be hidden. If an obsolete changeset have
non-obsolete descendant we can't simply hide it. And having a clear visual hint
that the changeset is obsolete is useful.
The main reason to make this minor change right now is to:
1) introduce an officiel user of the `ctx.obsolete()` method that will detect
breakage earlier than third party code (mutable, hgview)
2) Do not display any vocabulary related to obsolete. Such vocabulary will
require discussion.
