tortoisehg
GUI interface for Mercurial
-
4
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout devel:tools:scm/tortoisehg && cd $_ - Create Badge
Refresh
Refresh
Source Files
| Filename | Size | Changed |
|---|---|---|
| _service | 0000000500 500 Bytes | |
| _service:download_url:tortoisehg-3.0.2.tar.gz | 0008199459 7.82 MB | |
| rpmlintrc | 0000000241 241 Bytes | |
| tortoisehg.changes | 0000021376 20.9 KB | |
| tortoisehg.spec | 0000002999 2.93 KB |
Revision 21 (latest revision is 99)
Wolfgang Rosenauer (wrosenauer)
accepted
request 241928
from
Andrei Dziahel (develop7)
(revision 21)
New upstream release v3.0.2
Comments 8
Is there a reason why this is not in Factory?
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?
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.
It still is - HG 6.0.0 is out now, but tortoise is still on 5.9.3...
Yes, and there's no 6.0 release at https://www.mercurial-scm.org/release/tortoisehg/targz/
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.
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.
https://build.opensuse.org/request/show/853246
The tests are skipped on Leap because they fail with an xvfb error