- Dec 18, 2020
-
-
Georges Racinet authored
Fixing problems with obsolescence validation See merge request !47
-
Georges Racinet authored
-
Georges Racinet authored
The transaction on the receiving side will have obsolescence markers about changesets that were obsoleted before any exchange. Of course these are to be ignored.
-
Georges Racinet authored
We didn't test until now the case where the tag is 'tip' and it turns out that the tip of the obsolete repo is the obsoleted changeset in that case.
-
Georges Racinet authored
-
Georges Racinet authored
-
- Dec 16, 2020
-
-
Raphaël Gomès authored
Some repositories (particularly Octobus's `mercurial-devel` instance) do not want to exchange bookmarks, ever. This change applies to all exchange mechanisms relevant to Heptapod but was initially motivated by the new hg pull mirrors.
-
- Dec 17, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
This is a more common trap than with bookmarks, due to the separate changeset introducing the tag. Closes heptapod#393 Like the whole refs update analysis, will have to be kept when we don't mirror to Git.
-
Georges Racinet authored
Sometimes, the changesets created by `make_main_repo()` are just pollution.
-
Georges Racinet authored
In general, making a bookmark obsolete will resolve it: `hg amend` will move it to the successor, `hg prune` will move it to the parent. We found one corner case to make the target of a bookmark obsolete (`hg prune` when there is no parent). But there may be other ones (`hg split` maybe?)
-
- Dec 15, 2020
-
-
Georges Racinet authored
This is the bare minimum needed so that downstream users such as HGitaly can leverage it. The final version should probably become a property on the repo instance, but that will require actually more work, because it's not immediately clear if the standard Mercurial tooling applies well in this quite special case, namely: - we don't want any invalidation to occur before the explicit write at the end of transaction, for consistency reasons: the very mission of the state file is to represent the state at the beginning of transaction. - we're working under the assumption that all writes to the repository will update the state file. This is true, yet very specific to the Heptapod server environment. It's fine for `read_gitlab_branches` to raise `FileNotFoundException`. Will have to see for other exceptions though.
-
- Dec 14, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It's not needed, but it's even better if we don't activate it nevertherless.
-
Georges Racinet authored
In other words, adapt to our own config option removal!
-
- Dec 12, 2020
-
-
Georges Racinet authored
Of course, all this back-and-forth conversion from Git SHAs to Hg SHAs is getting long. The goal at this point is merely to make it available right away to HGitaly. Later on we'll have to split the branch analysis logic, and we'll start having a handler for Mercurial native projects, that will eventually not convert to Git at all.
-
Georges Racinet authored
As explained in the long docstring, this represents the latest state of branches *transmitted* to GitLab, i.e. has to be considered the state at beginning of transaction if there is an ongoing one (used precisely to deduce changes to notify GitLab about) or the current state if there is no ongoing transaction (read-only case). The read-only case will be useful for HGitaly right away: instead of doing expensive computations for each branch read, it will leverage this file if available.
-
Georges Racinet authored
These were long-standing TODOs.
-
Georges Racinet authored
The change in configuration flags for multiple heads is a non backwards compatible change.
-
Georges Racinet authored
Thanks to previous changes, the protection against multiple heads happens in `HeptapodGitHandler` instead of earlier in the transaction. We can thus stop lifting it when bookmarks are allowed, because the check now occurs once bookmarked heads have been taken out of the game. This is a boon for projects that track Git upstreams (like many components of Heptapod do, including the Rails application: they now can now use bookmarks to track their Git upstream branches and still be protected against multiple heads.
-
Georges Racinet authored
Necessary to test what happens with the default configuration.
-
Georges Racinet authored
Most users were using the core `experimental.single-head-pre-branch` only because Heptapod included it its "required" configuration. This is not the case any more, meaning we can let go of the monkeypatching introduced to avoid filtering obsolete heads twice.
-
Georges Racinet authored
whether we use it or not depends on the testing needs, but it's not part of the main code anyway.
-
- Dec 04, 2020
-
-
Georges Racinet authored
This was done in the stable branch, and gives us a nice uniformity. The `default` tag of the base image is ready for this.
-
Georges Racinet authored
This matches changes done in the base mercurial image so that its tag is now `default` instead of `latest`. At this point, the CI configuration of py-heptapod can be the same in its `stable` and `default` branches.
-
Georges Racinet authored
We need to use the `stable` tag of the base image for the `hg-current` job. Indeed too bad we can't just propagate the hg branch name, maybe it's time to do something about (uniformity makes the stable branch mergeable into the default branch without fear) It doesn't make much sense to run the `hg-default` and `hg-stable` jobs for the stable branch of py-heptapod, which won't change Mercurial versions, unless hg-stable is for the same hg x.y as hg-current (currently not the case).
-
- Dec 03, 2020
-
-
Georges Racinet authored
With the versioning scheme explained in heptapod#352, it doesn't make sense any more to have stable branches labelled after general Heptapod versions. With py-heptapod and semver, it's quite possible that we don't need to actually make default diverge from stable in some cycles. Still it will be convenient to have a clear reference. The alternative would be not to change, e.g., the HDK configuration, and then forget to update it once it becomes necessary.
-
- Dec 02, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The default configuration has been using it for a while. Of course in production Heptapod context, that's always provided (by the requirements shipping with the Rails app), but it can be missing in some development contexts - that is a pain, and potentially a waste of time because anything output on stderr is considered an error if spawned from Rails.
-
Georges Racinet authored
For instance, the missing dependency on `attrs` in 1.1.2 would have been detected with this.
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Dec 01, 2020
-
-
Georges Racinet authored
Part of heptapod#351 Suprisingly, reading HEAD with dulwich takes 25ms, and we were doing that for all branch/topic combination. The penalty is harsh when running for repositories with hundreds of branch/topic combinations. Caching this gets the time to perform a push on PyPy in my dev setup from 45s to about 4s. We could have avoided the caching, but there are some other callers, why spending occasional 25ms when we can avoid it? This is the occasion to move the setting logic in a separate method, awaiting the later refactorings for separation of "native" case from hg_git case.
-
- Nov 30, 2020
-
-
Georges Racinet authored
-
- Nov 29, 2020
-
-
Georges Racinet authored
This made 1.1.2 unusable outside of dev environments. Thought it was automatically provided because Mercurial uses it. Big mistake, Mercurial vendors it. Of course can't be detected by a pytest session...
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-