Edit Package tortoisehg

GUI interface for Mercurial

  • 1 derived packages
  • Download package
  • osc -A checkout devel:tools:scm/tortoisehg && cd $_
  • Create Badge
Source Files
Filename Size Changed
replace_mock_with_unittest_mock.patch 0000001553 1.52 KB
rpmlintrc 0000000241 241 Bytes
thg-6.4.2-tests.tar.gz 0000039736 38.8 KB
tortoisehg-6.4.2.tar.gz 0008932472 8.52 MB
tortoisehg.changes 0000056606 55.3 KB
tortoisehg.spec 0000004535 4.43 KB
Comments 8

Benjamin Greiner's avatar

bnavigator wrote

Is there a reason why this is not in Factory?

Wolfgang Rosenauer's avatar

wrosenauer wrote

IMHO one reason was that within this project it is/was not well maintained. Not necessarily because of us as maintainers but because upstream also seemed to be very slow.. So in the past it broke with almost every upgrade of mercurial and it was not reasonable to not update mercurial because tortoisehg was not available in a compatible version.

So that maybe was a reason. I cannot really tell if the situation changed since then and what @develop7 thinks about it nowadays?

Andrei Dziahel's avatar

develop7 wrote

Yeah, the upstream was slow and sloppy back then; things are improving now though — the release cycle has been promised to be in sync with Mercurial and so far they're keeping it; and they have started to publish release notes. Which is definitely a good sign.

I'd definitely gave them a try, but bear in mind outdated THG prevented Mercurial from upgrading and I don't know what does Tumbleweed policy say about that. We could work that around by bundling Mercurial to THG package, but I've no idea how to do that.

Mathias Homann's avatar

lemmy04 wrote

It still is - HG 6.0.0 is out now, but tortoise is still on 5.9.3...

Lukas Müller's avatar

expeehaa wrote

We could also relax the dependency on a specific Mercurial version. That could maybe break THG at runtime for a few days after a Mercurial release, but it could be in Factory without blocking Mercurial updates. I’m not entirely happy with that idea though, because we would deliberately accept breaking the user experience.

Manuel Jacob's avatar

mjacob wrote

To fix the build failures, we should either run the tests only "if %{with test}" or install pytest unconditionally (instead of "%if %{with test}"). I’m not sure what was the point of "%if %{with test}" originally.

Benjamin Greiner's avatar

bnavigator wrote

The tests are skipped on Leap because they fail with an xvfb error

openSUSE Build Service is sponsored by