thg issueshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues2020-06-21T09:55:04Zhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/777MQ: Restore keyboard shortcuts for reordering patches2020-06-21T09:55:04ZBitbucket ImporterMQ: Restore keyboard shortcuts for reordering patches*Created originally on Bitbucket by [anpol (Andrei Polushin)](https://bitbucket.org/%7Bdcdaa227-6a43-473f-af9a-e87581f8b7b4%7D/)*
There are several places where patches could be reordered using drag-n-drop, but there are no keyboard sho...*Created originally on Bitbucket by [anpol (Andrei Polushin)](https://bitbucket.org/%7Bdcdaa227-6a43-473f-af9a-e87581f8b7b4%7D/)*
There are several places where patches could be reordered using drag-n-drop, but there are no keyboard shortcuts for reordering.
And the usability of current drag-n-drop is rather far from excellent (e.g. it doesn't indicate that the drop target is **between** items). As a result, the reordering is hardly usable.
For now, I document the keyboard shortcuts available in Thg 1.x series:
* Shift+Up - Extend selection Up
* Shift+Down - Extend selection Down
* Alt+Shift+Up - No action (Now: Extend selection Up)
* Alt+Shift+Down - No action (Now: Extend selection Down)
(I guess, all combinations with Alt key should be reserved for future use and prohibited for now).
* Ctrl+Up - Apply next patch (the head of the queue is at the bottom)
* Ctrl+Down - Unapply last patch (the head of the queue is at the bottom)
(In thg 1.x, the head of the queue is at the top of the window, so the reverse keys were used)
* Ctrl+Shift+Up - Reorder: Move the selected patches visually Up in the Queue
* Ctrl+Shift+Down - Reorder: Move the selected patches visually Down in the Queue
(Reordering is valid when the contiguous range of unapplied patches are selected)
I propose to add the shortcuts to the RepoWidget at least.
There is the "Reorder Patches" dialog that duplicates the behavior of the RepoWidget. The shortcuts could be applied there too, and I suggest to add the proper (toolbar) buttons for patch reordering.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5367MQ: Selecting/applying a patch in Patch Queue widget causes error and no long...2020-06-21T11:18:38ZBitbucket ImporterMQ: Selecting/applying a patch in Patch Queue widget causes error and no longer updates details and revision history selection*Created originally on Bitbucket by [thomasdd (Thomas D.)](https://bitbucket.org/%7B8da0c5d2-9d85-454e-8331-a0535f3a8cc6%7D/)*
Patch Queue Widget behaviour has become painfully unresponsive, it always requires clicking around in the pat...*Created originally on Bitbucket by [thomasdd (Thomas D.)](https://bitbucket.org/%7B8da0c5d2-9d85-454e-8331-a0535f3a8cc6%7D/)*
Patch Queue Widget behaviour has become painfully unresponsive, it always requires clicking around in the patch list or even in the main revision history to force the details or commit view to update and actually show the selected and focused patch.
STR
- Select a change set in the main revision history, so that it gets shown in details/commit view below.
- In patch Queue Widget, press Enter on Patch 1 to apply it.
- Click or navigate to select another patch in the queue.
- Click on same patch in main revision history.
Actual results
- Applying a patch does NOT update details/commit view, which stubbornly continue to show what is selected in the main revision history, which is extremely useless and irritating. But when you click another patch in the queue widget and then click again on the applied patch, details will update to show the selected and focused patch. Which is very cumbersome.
- Selecting unapplied patches in the Queue widget does not update details at all (again very irritating), but shows an error in status bar: "Can't find revision 'patchname'". So that's where we used to update the revision history selection list to be in sync with the selected patch in the queue widget. Regression. Makes the entire Patch Queue widget almost a no-op.
- Only selecting any patches in main revision list will reliably update the details/commit display.
Expected behaviour
- Applying a patch must obviously update revision list selection to that patch to show its details. Regression I believe.
- Clicking on a patch in the queue widget (applied or not) must always update revision list selection, too, as it used to do (please fix this regression asap!!! See #5005 where I documented the previous correct behaviour).
- issue #4990: Please also cover the case where a patch is selected, but not focused, maybe another main revision shown, then user clicks on already selected patch to see it.
- issue #5005: Reverse case: Selecting a (single) patch in the main revision list should also update the selection in the patch queue widget to the same patch, to avoid confusing UI states. For consistency of UI state, I guess we should also keep selections of multiple patches in sync between the two widgets.
The desired overall behaviour is actually very simple:
- Please always keep patch selections in sync between patch queue and main revision list, especially for single patch selections.
- Please always ensure that a patch which is focused and selected in the queue widget will update details/commit view accordingly.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4471MQ: Wrong commit message shown when selecting working directory before applyi...2020-06-21T10:59:53ZBitbucket ImporterMQ: Wrong commit message shown when selecting working directory before applying second patch*Created originally on Bitbucket by [thirteen (Andreas Bilger)](https://bitbucket.org/%7Bad66f259-1fbf-4353-be5f-2fa71de38f06%7D/)*
Scenario (see attached sample repository):
* one changeset "Empty repository"
* 3 unapplied patches:...*Created originally on Bitbucket by [thirteen (Andreas Bilger)](https://bitbucket.org/%7Bad66f259-1fbf-4353-be5f-2fa71de38f06%7D/)*
Scenario (see attached sample repository):
* one changeset "Empty repository"
* 3 unapplied patches: `a` ("AAA"), `b` ("BBB"), `c` ("CCC")
Reproduction Steps:
* Changeset 0 is selected
* Select `Working Directory`
* Apply patch `a`
* Changeset 1 with patch `a` is selected, commit message shows: "AAA" (correct)
* Select `Working Directory`
* Apply patch `b`
* Changeset 2 with patch `b` is selected, commit message shows: "AAA" (BUG, should be "BBB")
* Select `Working Directory`
* Apply patch `c`
* Changeset 3 with patch `c` is selected, commit message shows: "AAA" (BUG, should be "CCC")
The shown wrong commit message gets saved when clicking QRefresh. This can cause you to lose the original patch commit message.
The buggy behavior does **not** occur in the following circumstances:
* if you do not select the `Working Directory` before applying the second/third patch
* if your setting `Workbench -> Initial revision` is set to `workingdir`
Versions affected (tested):
* 3.7.2
* 3.6.3
*Attachments:* [Repository.zip](/uploads/aa06b3b8510089e87d10f7fa9b578615/Repository.zip)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4399msi: Can't download archive (ZIP) file from Web Server2020-06-21T10:58:19ZBitbucket Importermsi: Can't download archive (ZIP) file from Web Server*Created originally on Bitbucket by Anonymous*
TortoiseHG 3.6.2. When I try to download repository as ZIP archive an exception occurs:
```
#!python
127.0.0.1 - - [21/Dec/2015 08:57:20] Exception happened during processing request...*Created originally on Bitbucket by Anonymous*
TortoiseHG 3.6.2. When I try to download repository as ZIP archive an exception occurs:
```
#!python
127.0.0.1 - - [21/Dec/2015 08:57:20] Exception happened during processing request '/archive/7d4462a5a56a.zip':
Traceback (most recent call last):
File "mercurial\hgweb\server.pyo", line 80, in do_POST
File "mercurial\hgweb\server.pyo", line 73, in do_write
File "mercurial\hgweb\server.pyo", line 141, in do_hgweb
File "mercurial\hgweb\hgweb_mod.pyo", line 281, in run_wsgi
File "mercurial\hgweb\hgweb_mod.pyo", line 396, in _runwsgi
File "mercurial\extensions.pyo", line 183, in closure
File "hgext\largefiles\overrides.pyo", line 903, in hgwebarchive
File "mercurial\hgweb\webcommands.pyo", line 1092, in archive
File "mercurial\extensions.pyo", line 183, in closure
File "hgext\largefiles\overrides.pyo", line 944, in overridearchive
File "hgext\largefiles\overrides.pyo", line 938, in write
File "mercurial\archival.pyo", line 243, in addfile
File "zipfile.pyo", line 1246, in writestr
File "mercurial\archival.pyo", line 192, in __getattr__
AttributeError: 'wsgirequest' object has no attribute 'seek'
```
May be this is a bug [4492](https://bz.mercurial-scm.org/show_bug.cgi?id=4492). But TortoiseHG use Python 2.7.9 that not fixed this bug.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4221Multiple issue trackers2020-06-21T10:54:37ZBitbucket ImporterMultiple issue trackers*Created originally on Bitbucket by [NN](https://bitbucket.org/%7Bf66e4503-cb56-489c-b87b-d9fb5db1dd37%7D/)*
Currently THG allows only one issue tracker.
It would be nice to allow two and more since over the time the bugtracking system...*Created originally on Bitbucket by [NN](https://bitbucket.org/%7Bf66e4503-cb56-489c-b87b-d9fb5db1dd37%7D/)*
Currently THG allows only one issue tracker.
It would be nice to allow two and more since over the time the bugtracking systems can change but links for old ones are important too.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/524Narrowing down Detect Copies/Renames search2020-06-21T09:49:45ZBitbucket ImporterNarrowing down Detect Copies/Renames search*Created originally on Bitbucket by Anonymous*
Detect Copies/Renames works quite fast when searching for renamed files ("Only consider deleted files" option), but finding copies requires scanning entire repository, which takes really lo...*Created originally on Bitbucket by Anonymous*
Detect Copies/Renames works quite fast when searching for renamed files ("Only consider deleted files" option), but finding copies requires scanning entire repository, which takes really long time on a ~300MB/20.000 files repository (not to mention that it also requires ~1GB of memory). Selecting only certain directories for the search would certainly speed this process up.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4420Need a maximum width for Description column in Repo view2020-06-21T10:58:44ZBitbucket ImporterNeed a maximum width for Description column in Repo view*Created originally on Bitbucket by [Ewen Wallace](https://bitbucket.org/%7Bf7ccd238-7e3b-408e-a193-51881af16383%7D/)*
Greetings and thank you for all your hard work on THg
Every time I open a new repo in Workbench I have to resize t...*Created originally on Bitbucket by [Ewen Wallace](https://bitbucket.org/%7Bf7ccd238-7e3b-408e-a193-51881af16383%7D/)*
Greetings and thank you for all your hard work on THg
Every time I open a new repo in Workbench I have to resize the description column because it has resized to the longest description, hiding all the columns on the right. Can I set a maximum width for this column?
I notice this is also a problem for other columns such as Author so maximum widths for those would be good too.
Actually, it would be good to set a default set of column widths so any new repo in the workbench was initially sized to these. widths
Windows 10 x64 (just in case it is a local thing).
cheers
Ewenhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4939need coloring graph for bookmarks branches2020-06-21T11:09:35ZBitbucket Importerneed coloring graph for bookmarks branches*Created originally on Bitbucket by [Alex Rayne (Александр Литягин)](https://bitbucket.org/%7Ba08cf82d-1da1-46f4-8019-7f030383d366%7D/)*
Hallow!
Git workflow style need havily use bookmarks vs named branches. So, at present, this bookm...*Created originally on Bitbucket by [Alex Rayne (Александр Литягин)](https://bitbucket.org/%7Ba08cf82d-1da1-46f4-8019-7f030383d366%7D/)*
Hallow!
Git workflow style need havily use bookmarks vs named branches. So, at present, this bookmaked branches are in single color.
it would be very helpful to color this bookmarks. this can solve #4938
no-named branches would be more distinguisheble if it have differ colour saturation or linestyle.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5952Network drive letters are converted to UNC paths2023-11-28T19:01:10ZMichael StammbergerNetwork drive letters are converted to UNC pathsI have a lot of repositories located on a network drive (Windows Server, mapped by "net use ...").
After updating from TortoiseHg 6.0.0 to 6.5.1. the Workbench handle these repositories in a strange way:
- The repositories are listed in...I have a lot of repositories located on a network drive (Windows Server, mapped by "net use ...").
After updating from TortoiseHg 6.0.0 to 6.5.1. the Workbench handle these repositories in a strange way:
- The repositories are listed in the Repository registry (TreeView) as before.
- On opening one of these repositories by double click the Workbench freezes for some time before opening it.
- Then the repository **is added a second time** to the Repository registry, but with a different icon (planet earth probably representing a network connection).
- The path to the new added repository has changed from the network drive letter to its UNC path (and this new added repository is actually opened).
The problem with the UNC path is that the Windows command line can't work with them correctly. Some hooks are not processed as expected, e.g. changegroup:
> % hg push "N:\Projects\MyProject"\
> pushing to N:\Projects\MyProject\
> searching for changes\
> adding changesets\
> adding manifests\
> adding file changes\
> added 79 changesets with 308 changes to 53 files (+1 heads)\
> "\\\\SRV6\Entwicklung\Projects\MyProject"\
> **CMD.EXE wurde mit dem oben angegebenen Pfad als aktuellem Verzeichnis gestartet.**\
> **UNC-Pfade werden nicht unterstützt.**\
> **Stattdessen wird das Windows-Verzeichnis als aktuelles Verzeichnis gesetzt.**\
> abort: no repository found in 'C:\Windows' (.hg not found)\
> warning: changegroup hook exited with status 255\
> [command completed successfully Fri Sep 29 12:11:56 2023]
Why is the network drive letter path replaced by UNC path?
TortoiseHg version 6.5.1 with Mercurial-6.5.1, Python-3.9.13, PyQt-5.15.7, Qt-5.15.2, Windows 10 Pro 22H2.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/1903No File history for largeFiles2020-06-21T10:17:41ZBitbucket ImporterNo File history for largeFiles*Created originally on Bitbucket by [justAnHgUser](https://bitbucket.org/%7B8650f358-108b-4532-88ca-fd9a3adb053c%7D/)*
In my Repository largefile extension is active:
[extensions]
largefiles =
[largefiles]
minsize = 4
p...*Created originally on Bitbucket by [justAnHgUser](https://bitbucket.org/%7B8650f358-108b-4532-88ca-fd9a3adb053c%7D/)*
In my Repository largefile extension is active:
[extensions]
largefiles =
[largefiles]
minsize = 4
patterns = re:.*\.(doc|docx|xls|xlsx|pdf)$
usercache = C:\Mercurial\largefiles
If i commit changes with files, which should be treated as large files, i get asked if i should add the affected files as normal or large files.
Independend of my choice, Tortoise doesn´t show file histories for such files.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/2360no match found2020-06-21T10:27:09ZBitbucket Importerno match found*Created originally on Bitbucket by Anonymous*
~~~~
#!python
** Mercurial version (2.3.2). TortoiseHg version (2.5.1)
** Command:
** CWD: C:\Windows\system32
** Encoding: cp1252
** Extensions loaded:
** Python version: 2.7.3 (...*Created originally on Bitbucket by Anonymous*
~~~~
#!python
** Mercurial version (2.3.2). TortoiseHg version (2.5.1)
** Command:
** CWD: C:\Windows\system32
** Encoding: cp1252
** Extensions loaded:
** Python version: 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
** Windows version: sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1')
** Processor architecture: x64
** Qt-4.8.0 PyQt-4.9.1
Traceback (most recent call last):
File "tortoisehg\hgqt\merge.pyo", line 655, in run
File "mercurial\context.pyo", line 1000, in dirty
File "mercurial\context.pyo", line 919, in modified
File "mercurial\util.pyo", line 245, in __get__
File "mercurial\context.pyo", line 873, in _status
File "mercurial\localrepo.pyo", line 1577, in status
File "mercurial\context.pyo", line 519, in cmp
File "mercurial\context.pyo", line 502, in size
File "mercurial\util.pyo", line 245, in __get__
File "mercurial\context.pyo", line 416, in _filerev
File "mercurial\util.pyo", line 245, in __get__
File "mercurial\context.pyo", line 410, in _filenode
File "mercurial\revlog.pyo", line 766, in lookup
LookupError: data/myMethods/maize project/code/maize tracking/ver1 - tip only/ba_interp2.mexw64.i@7d859b8c7548: no match found
~~~~https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/451No menu items on Ubuntu 10.102020-06-21T09:48:13ZBitbucket ImporterNo menu items on Ubuntu 10.10*Created originally on Bitbucket by [tbrander (Tom Brander)](https://bitbucket.org/%7B90d84ec6-6126-414f-a2ba-6338eac9f05f%7D/)*
Tried several install options but never got any context menus, never got any menu item on main programs men...*Created originally on Bitbucket by [tbrander (Tom Brander)](https://bitbucket.org/%7B90d84ec6-6126-414f-a2ba-6338eac9f05f%7D/)*
Tried several install options but never got any context menus, never got any menu item on main programs menu either?https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/3279"Nonetype has no attribute readline" when changing repo port2020-06-21T10:34:35ZBitbucket Importer"Nonetype has no attribute readline" when changing repo port*Created originally on Bitbucket by [ekolis (Ed Kolis)](https://bitbucket.org/%7B952af717-5772-4ff3-9551-eb66749b1c88%7D/)*
One of the repos I'm using changed its port from 65001 to 3690 without changing the rest of its URL. I changed t...*Created originally on Bitbucket by [ekolis (Ed Kolis)](https://bitbucket.org/%7B952af717-5772-4ff3-9551-eb66749b1c88%7D/)*
One of the repos I'm using changed its port from 65001 to 3690 without changing the rest of its URL. I changed that in TortoiseHG so I could continue using the repo, but now I get this error whenever I try to pull from it.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5634Nonsensical error: "Could not open network socket" at startup2020-10-10T23:15:35Zteo1978Nonsensical error: "Could not open network socket" at startupEvery time I launch thg I get these errors in the terminal where I run thg from:
```
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Sessi...Every time I launch thg I get these errors in the terminal where I run thg from:
```
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Session management error: Could not open network socket
```
The host name of my machine happens to be "localhost", because this is a recently-installed openSUSE, and strangely enough, on installation openSUSE didn't prompt me to choose a name for the machine (I think that's stupid if you ask me), so I guess that's the default name.
I mention this just in case the confusion between "localhost" as a name for the host, as opposed to the conventional name for the loopback network interface (i.e. 127.0.0.1), is in any way related to the issue (or anyway it could lead to confusion when trying to make sense of the above error messages).https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/2233Non-visual diff2020-06-21T10:24:36ZBitbucket ImporterNon-visual diff*Created originally on Bitbucket by [mbutscher (Michael Butscher)](https://bitbucket.org/%7Bb65b6412-53cb-4df6-93c5-5f561e3390cc%7D/)*
TortoiseHg versions up to 1.1.9 provided to show also a non-visual diff instead of the visual one. It...*Created originally on Bitbucket by [mbutscher (Michael Butscher)](https://bitbucket.org/%7Bb65b6412-53cb-4df6-93c5-5f561e3390cc%7D/)*
TortoiseHg versions up to 1.1.9 provided to show also a non-visual diff instead of the visual one. It would be nice to have this again because sometimes the concise textual diff format is more helpful.
In combination with the option to select hunks it was possible to easily prepare a single specialized patch which included selected parts of multiple revisions.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/791No option to clone from an https repository with stored host fingerprint veri...2020-06-21T09:55:19ZBitbucket ImporterNo option to clone from an https repository with stored host fingerprint verification*Created originally on Bitbucket by Anonymous*
TortoiseHG provides the facilities to push/pull from an HTTP(S) repository using Verification with stored host fingerprint.
However this option is not available for the clone option. Ide...*Created originally on Bitbucket by Anonymous*
TortoiseHG provides the facilities to push/pull from an HTTP(S) repository using Verification with stored host fingerprint.
However this option is not available for the clone option. Ideally the same security dialog used for the Sync option is available in the Clone dialog to offer the same options.
The latest unstable release offers No Host validation option, but no option to perform Verification using stored host fingerprint.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4673No option to merge into local discarding local changes (i.e. keep "other")2020-06-21T11:04:18ZBitbucket ImporterNo option to merge into local discarding local changes (i.e. keep "other")*Created originally on Bitbucket by Anonymous*
Let's say I have a `default` branch and a `somebranch` branch. I want to merge them into the `default` branch, keeping everything "as is" from the `somebranch` branch. That is, wherever the...*Created originally on Bitbucket by Anonymous*
Let's say I have a `default` branch and a `somebranch` branch. I want to merge them into the `default` branch, keeping everything "as is" from the `somebranch` branch. That is, wherever there might be any sort of conflict, take the `somebranch` version. Override the local version completely.
There should be an obvious no-brainer option to do that from TortoiseHG, and there isn't.
I update to the tip of the `default` branch, then I right-click on the tip of the `somebranch` branch, and I get the dialog in the attached screenshot. There's an option "discard all changes from the `other` revision". That's great, but there should also be an exactly opposite option: "discard all changes from the local revision".
Of course you can just normally merge, and then in the list of conflicting files, choose "keep other" for each one. But you shouldn't have to go through all that.
*Attachments:* [thg](/uploads/07569234ebe0d0615f77316fe01234ce/thg.png)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5819No pagination of hg output as of version 6.22022-10-31T14:53:42ZMartin GiesekingNo pagination of hg output as of version 6.2I've just updated TortoiseHg to version 6.2 on a Windows machine and noticed that the output of `hg` commands is no longer paginated, i.e. the pager doesn't seem to be executed. My settings from _mercurial.ini_ are recognized because `hg...I've just updated TortoiseHg to version 6.2 on a Windows machine and noticed that the output of `hg` commands is no longer paginated, i.e. the pager doesn't seem to be executed. My settings from _mercurial.ini_ are recognized because `hg config` lists them but they have no effect:
```
pager.pager=less -R -F -X
pager.attend=annotate, cat, diff, export, glog, help, log, qdiff, qseries, status, tags
pager.ignore=version, help, update
```
Also, when removing all pager settings or replacing `less` with something else doesn't change anything. The values of environment variable `PAGER` and `ui.paginate` (as mentioned in `hg help pager`) have no effect either. Regardless of the settings, the output is not piped through any pager.
Is this an issue with thg's bundled Mercurial or should I report this upstream as well?Windows py3 releasehttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5420No projrc module found on v4.9.1 (migration from v3.3.3)2020-06-21T11:19:39ZBitbucket ImporterNo projrc module found on v4.9.1 (migration from v3.3.3)*Created originally on Bitbucket by Anonymous*
I'm currently using **TortoiseHg v3.3.3** as versioning software for my **C# source code**. Since it is a very old version, I recently tried to update to the latest version **v4.9.1**.
I...*Created originally on Bitbucket by Anonymous*
I'm currently using **TortoiseHg v3.3.3** as versioning software for my **C# source code**. Since it is a very old version, I recently tried to update to the latest version **v4.9.1**.
In many of my code projects (repositories) I'm using the **projrc module** (so a `projrc` file) to remap the folder for dependency libraries that are treated as **subrepositories**.
In this way, if I need, I can map each of my repository to a specific version of each subrepository, since the subrepository folder is cloned independently inside each repository where I need.
After installing **TortoiseHg v4.9.1**, while trying to clone an existing repository, I immediately get an error if the repository is referencing subrepositories using projrc. The error simply says that:
No projrc module was found.
I tried by checking the TortoiseHg Settings under Extensions menu and I can only see that the `projrc` module checkbox is checked. I also tried to uncheck/check again, but the error still persists. If I search inside the TortoiseHg v4.9.1 program folder in my PC for `projrc` module files, I find nothing. Instead, I find some `.pyd` file, while searching inside the v3.3.3.
What should I do? Is there a way to get back the `projrc` module? Is this a bug?
Otherwise, what alternatives do I have to get the same type of repository/subrepository management?
Here follows an example to better understand my usage of the `projrc` module.
####Example:
Main application repository:
`MyCompany.ServerApp`
Dependecy libraries repositories:
```
MyCompany.SharedLibrary1
MyCompany.SharedLibrary2
```
`.hgsub` file content (the file is inside main application repository folder, under `C:\source\MyCompany\MyCompany.ServerApp\.hgsub`):
```
MyCompany.SharedLibrary1 = MyCompany.SharedLibrary1
MyCompany.SharedLibrary2 = MyCompany.SharedLibrary2
```
`projrc` file content (the file is inside main application repository folder, under `C:\source\MyCompany\MyCompany.ServerApp\.hg\projrc`):
```
#\ projrc encoding check, line must begin with '#\ '
[subpaths]
Z:\\Development\\hgRepo\\MyCompany.ServerApp/MyCompany.SharedLibrary1 = Z:/Development/hgRepo/SharedLibraries/MyCompany.SharedLibrary1
Z:\\Development\\hgRepo\\MyCompany.ServerApp/MyCompany.SharedLibrary2 = Z:/Development/hgRepo/SharedLibraries/MyCompany.SharedLibrary2
```
#####Note:
`/` and `\` (single and double) are correctly used as requested by `projrc` module.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4563No subversion bindings for python available for Subversion 1.9+2020-06-21T11:01:44ZBitbucket ImporterNo subversion bindings for python available for Subversion 1.9+*Created originally on Bitbucket by [kelvin_green (Kelvin Green)](https://bitbucket.org/%7Bf860b9ee-1fb9-4b5c-bc61-50a559cdd5d2%7D/)*
On the libsvn wiki page, the downloads for svn bindings are for SVN 1.7.5. If used with hgsubversion t...*Created originally on Bitbucket by [kelvin_green (Kelvin Green)](https://bitbucket.org/%7Bf860b9ee-1fb9-4b5c-bc61-50a559cdd5d2%7D/)*
On the libsvn wiki page, the downloads for svn bindings are for SVN 1.7.5. If used with hgsubversion to clone a repository created with SVN 1.9 or greater, user will encounter an error similar to the following:
> hg clone 'file:///C:/svn_repo'
>destination directory: trunk
>abort: Unable to open an ra_local session to URL
>Unable to open repository 'file:///C:/svn_repo'
>'C:\svn_repo\db\format' contains invalid filesystem format option 'addressing logical'
For SVN repos created with SVN 1.9 using FSFS format 7, older versions of SVN can't access the repo as has been documented several times (http://stackoverflow.com/a/33264998)
Suggest adding subversion bindings for python for the newest version of SVN to the downloads section as downgrading the version of used to create a repository isn't possible in some situations.