tortoisehg

Edit Package tortoisehg

GUI interface for Mercurial

Refresh
Refresh
Source Files
Filename Size Changed
rpmlintrc 0000000241 241 Bytes
thg-6.6.3-tests.tar.gz 0000039757 38.8 KB
tortoisehg-6.6.3.tar.gz 0008933150 8.52 MB
tortoisehg.changes 0000058163 56.8 KB
tortoisehg.spec 0000004861 4.75 KB
Latest Revision
Lukas Müller's avatar Lukas Müller (expeehaa) accepted request 1200715 from Lukas Müller's avatar Lukas Müller (expeehaa) (revision 99)
- Use existing python RPM macros instead of custom ones.
Comments 8

Benjamin Greiner's avatar

Is there a reason why this is not in Factory?


Wolfgang Rosenauer's avatar

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

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

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



Lukas Müller's avatar

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

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

https://build.opensuse.org/request/show/853246

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

openSUSE Build Service is sponsored by