Modifying the config file is complicated and error prone, but there hasn't been
any other option aside from setting `HGRCPATH` to point to a standalone file.
Starting with Mercurial 7.0 (scheduled for March 2025), there's now a global
option to specify one or more additional config files on the command line,
without disabling the normal system and user level config file processing.[1]
Since I'm not sure what the minimum supported Mercurial is for this project,
this includes an extension that backports the same option if it is not present
in the version of Mercurial that is used, and does nothing if Mercurial natively
supports it. I tested back to Mercurial 6.0, which should be more than
sufficient- 6.1.4 (June 2022) was the last release to support Python 2 (which
has been EOL since Jan 2020), and the Python 3 support before that release was
considered experimental. It likely works in earlier versions, but there's a
definite minimum of 4.9 (Feb 2019), due to the `exthelper` module import.
Without the need to modify a possibly existing file and then restore it when
done, a bunch of code falls away, and the tests that supported it.
[1] https://repo.mercurial-scm.org/hg/rev/25b344f2aeef
I can't point to a specific error, but modifying a singleton and reusing it is
a good way to get unexpected state. The extension adding won't collect
additional state (it's add-if-not-present), but the underlying
`java.util.HashMap` isn't threadsafe. Any differences in the environment map
when this is called would alter that state of anything else that still held a
configuration (and it also uses `HashMap`), and the pending changeset, encoding,
and HgBin settings would be overwritten for everybody outright.
There's only a default constructor for this class, so nothing to pass along in
the constructor. I don't *think* this was the cause of the random auth failures
mentioned in the previous commit, but it's easy to avoid these potential
problems.
There was previously a weird duality where a simple push to or pull from a
repository hosted by SCM-Manager would load all of the system and user level
config files, but they were ignored when importing a repository. I found this
out when importing an LFS repo, and it eventually failed with a message that the
LFS extension needs to be enabled, even though it was enabled globally. The
global config should typically never be ignored, because some repositories are
unreadable without certain extensions or configurations.
The JavaHg API here mirrors the hg behavior for the `HGRCPATH` environment
variable- not setting it (or null here) uses the default config resolution, and
`""` (the default in JavaHg for some reason) disables default config resolution.
The repository initialization code in JavaHg also uses `""`, and there's no way
to alter that from the outside. But that appears to be harmless, so I'm
ignoring that for now. Note that this may only have been a problem on
non-Windows systems- setting an environment variable to empty on Windows
*unsets* the variable, even in the `_wputenv()` API, which is what we want.
After this, normal push/pull operations continue to use the global config. But
now imports from the SCM-Manager UI, the hooks run during a push, and any other
commands that are run through JavaHg will see a consistent configuration. LFS
(and maybe largefiles- I haven't tested it) repository imports now work. (I
wouldn't say "supported" yet because it doesn't pull the blobs. The largefiles
extension has a command for doing this, but the LFS extension doesn't. The
stopgap for this is to run `hg verify` to download the blobs, but that won't
work here with the way subrepos aren't nested as expected. I can work on a
command on the hg side to fill this gap.)
One final thing to note here- as I was testing, I initially got authentication
failures when trying to pull. It happened several times as I added more and
more logging, then disappeared, and I wasn't able to trigger it again as I
backed off the logging to get to this change alone. The auth info is written to
the repository's hgrc file, so a change to whether or not the global
configuration is processed is irrelevant. The next couple of commits will try
to improve the related code.
The review plugin does not explicitly check, if the
branch provider is supported in events. It only checks,
whether the repository supports branches per se.
Therefor, if a tag is created from the ui, an internal server
error is thrown. We prevent this by implementing a
simple branch provider here, too.
The line `allowfilter = true` is inserted both in new Git repositories
and existing ones (via an UpdateStep). This enables clones with
`--filter` parameters.
Co-authored-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
With this change, most modifications of git repositories (like inserting, deleting and updating files and merging branches) do no longer work inside clones held in temporary working directories but are done directly inside the bare git repository data. This resolves in a massive performance boost for the editor plugin and pull requests, especially in larger repositories.
Co-authored-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
Committed-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
Document titles represent the pages, for example in lists
with bookmarks. They are important for navigation and
orientation in websites. If the offer or the content of the
page is not labeled, orientation is impaired.
This changes the behavior for setting document titles.
The functionality has been removed from the Page and
Title components and is now represented by `useDocumentTitle`
hook to better describe the content of inividual pages.
Co-authored-by: Anna Vetcininova<anna.vetcininova@cloudogu.com>
To still support the editor plugin, a new field in the
browse command results is needed to indicate, whether
such a result or rather the requested revision can be
modified by a new commit.
This is the case, when
- for Subversion repositories either the new 'head' or the
latest revision has been requested, or
- for Git and HG when a branch (or the default by specifying
no concrete revision) has been used.
Over the course of a very long time, the interpolation strings for the versions in the scm-git-plugin and scm-svn-plugin had not been processed. One assumption was that this was related to a discontinued Maven process.
The behavior was now realized by two tasks process after the gradle build lifecycle step. It remains to be discussed whether it's worth the time and effort to integrate the change into the smp plugin.
We encountered NullPointerExceptions during hg repository imports. This happened, when neither authentication nor proxy definions had been given. In this case, no hgrc will be created and therefore we get the exception in the clean-up step. Now, the clean-up is only triggered, if the hgrc had been created beforehand.
To prevent further error in the clean-up, we no catch other potential exceptions and log them but do not let them break the import.
Pushed-by: Rene Pfeuffer<rene.pfeuffer@cloudogu.com>
Co-authored-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
The BaseReceivePackFactory re-used the GitReceiveHook. The problem is, that the hook is not thread safe. Due to the re-usage, the repository could have been changed during processing post receive hooks. With this, the factory will always create a new receive pack.
Pushed-by: Rene Pfeuffer<rene.pfeuffer@cloudogu.com>
Co-authored-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
Committed-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
A notification will be displayed when an external user
management system is activated to inform that users
created within the SCMM will not be transferred to the
external system.
Co-authored-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
The sub repositories did not show up in the source view. This fixes python errors for the computation of sub repositories in hg.
Pushed-by: Rene Pfeuffer<rene.pfeuffer@cloudogu.com>
Co-authored-by: René Pfeuffer<rene.pfeuffer@cloudogu.com>
