Tortoisehg 255 ошибка

.Добрый день. При попытке залить проект под контроль версий, выдает ошибку 255.
Если заливать файлы под контроль версий на сервер поэтапно по 2-3 файла, то — заливается норм, когда больше файлов пытаешься добавить в коммит,то возникает эта ошибка. Причем на другой сервер нормально все заливается сразу скопом. Подскажите, в чем может быть проблема?

Данные сервера:
Apache 2.4.41,
PHP 7.4.3,
MySQL Ver 8.0.22-0,
NodeJS v15.8.0,
Samba,
ubuntu 20.04

error 255

Текст ошибки

    ** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 5.0.2)
** Extensions loaded: tortoisehg.util.hgcommands, tortoisehg.util.partialcommit, tortoisehg.util.pipeui, tortoisehg.util.win32ill, tortoisehg.util.hgdispatch
** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 5.0.2)
** Extensions loaded: tortoisehg.util.hgcommands, tortoisehg.util.partialcommit, tortoisehg.util.pipeui, tortoisehg.util.win32ill, tortoisehg.util.hgdispatch
Traceback (most recent call last):
  File "hg", line 50, in <module>
  File "mercurial\dispatch.pyo", line 99, in run
  File "mercurial\dispatch.pyo", line 225, in dispatch
  File "mercurial\dispatch.pyo", line 376, in _runcatch
  File "mercurial\dispatch.pyo", line 384, in _callcatch
  File "mercurial\scmutil.pyo", line 167, in callcatch
  File "mercurial\dispatch.pyo", line 367, in _runcatchfunc
  File "mercurial\dispatch.pyo", line 1021, in _dispatch
  File "mercurial\dispatch.pyo", line 756, in runcommand
  File "mercurial\dispatch.pyo", line 1030, in _runcommand
  File "mercurial\dispatch.pyo", line 1018, in <lambda>
  File "mercurial\util.pyo", line 1680, in check
  File "mercurial\commands.pyo", line 5300, in serve
  File "mercurial\server.pyo", line 147, in runservice
  File "mercurial\commandserver.pyo", line 405, in run
  File "mercurial\commandserver.pyo", line 346, in serve
  File "mercurial\commandserver.pyo", line 319, in serveone
  File "mercurial\commandserver.pyo", line 303, in runcommand
  File "mercurial\dispatch.pyo", line 225, in dispatch
  File "mercurial\dispatch.pyo", line 376, in _runcatch
  File "mercurial\dispatch.pyo", line 384, in _callcatch
  File "mercurial\scmutil.pyo", line 167, in callcatch
  File "mercurial\dispatch.pyo", line 367, in _runcatchfunc
  File "tortoisehg\util\hgdispatch.pyo", line 23, in _dispatch
  File "mercurial\dispatch.pyo", line 1021, in _dispatch
  File "mercurial\dispatch.pyo", line 756, in runcommand
  File "mercurial\dispatch.pyo", line 1030, in _runcommand
  File "mercurial\dispatch.pyo", line 1018, in <lambda>
  File "mercurial\util.pyo", line 1680, in check
  File "mercurial\util.pyo", line 1680, in check
  File "tortoisehg\util\partialcommit.pyo", line 34, in partialcommit
  File "mercurial\util.pyo", line 1680, in check
  File "mercurial\commands.pyo", line 1647, in commit
  File "mercurial\commands.pyo", line 1722, in _docommit
  File "mercurial\cmdutil.pyo", line 2434, in commit
  File "mercurial\commands.pyo", line 1720, in commitfunc
  File "mercurial\localrepo.pyo", line 177, in wrapper
  File "mercurial\localrepo.pyo", line 2548, in commit
  File "mercurial\localrepo.pyo", line 177, in wrapper
  File "mercurial\localrepo.pyo", line 2622, in commitctx
  File "mercurial\localrepo.pyo", line 2434, in _filecommit
  File "mercurial\filelog.pyo", line 135, in add
  File "mercurial\filelog.pyo", line 106, in addrevision
  File "mercurial\revlog.pyo", line 1905, in addrevision
  File "mercurial\revlog.pyo", line 1916, in addrawrevision
  File "mercurial\revlog.pyo", line 544, in _indexfp
  File "mercurial\store.pyo", line 571, in __call__
  File "mercurial\vfs.pyo", line 420, in __call__
  File "mercurial\util.pyo", line 2314, in makedirs
WindowsError: [Error 50] : '\\\\vsrvdev1\\web\\sez\\dev\\.hg/store\\data/~f4~fb~e2'
cmdserver: процесс завершился неожиданно с кодом 255

I am using Tortoise-Hg for cloning a fork from CodePlex and cloning stops in the middle of the process. I have tried it more than 6 times and it does have a problem.

I am using the visual client of Tortoise-Hg and I gave the source as https://hg.codeplex.com/forks/xxx/xxxx and selected a destination

First used compressed method

This is what appeared in the command prompt

 % hg clone --verbose -- https://hg.codeplex.com/forks/xxx/xxxx xxxx

But the process start quite fast and then it get hung up.

requesting all changes
adding changesets[Happen Fast]
adding manifests[Happen Fast]
adding file changes[Hangs in the middle]
transaction abort!
rollback completed
abort: stream ended unexpectedly (got 147721 bytes, expected 422805)
[command returned code 255 Sun Mar 31 15:52:26 2013]

Then I tried uncompressed method

 % hg clone --uncompressed --verbose -- https://hg.codeplex.com/forks/xxx/xxxx xxxx

That also stops in the middle of the process.

streaming all changes
4033 files to transfer, 37.2 MB of data
abort: unexpected response from remote server: empty string
[command returned code 255 Sun Mar 31 15:22:44 2013]

I tried it the 7th time and It went far more than previous tries but got more bytes got 74673 bytes, expected 256973

What is the wrong with this, I have used same version of Tortoise-Hg before for cloning CodePlex projects. This is very time consuming. Is there something wrong of what I am doing?. How can I resolve this issue?

Home
Problems

I am trying to clone a repository via TortoiseHg.

I take paste the clone line into TortoiseHg

hg clone http://myusername@servername/hglab/hg/myslug/myreponame

and next receive the error message:

repository hg clone http://myusername@servername/hglab/hg/myslug/myreponame not found

[Code: 255]

A few things: When I paste the same line a cmd window, the clone happens as I would expect. no errors, all is well, I can make changes, committ, push them back up, etc…

I next added a .hgrc file as well as mercurial.ini file with [ui] and [auth] sections.

I know the cmd line version is using the .hgrc file because when I remove it, I am asked for a username and then a password.

When .hrgc is back in place in my c:\users\myusername folder then from the command line I leave off the user id.

e.g. with .hgrd in place I can use:

hg clone http://servername/hglab/hg/myslug/myreponame and everything works well.

I added the [auth] stuff to mercurial.ini to see if it made a difference but no good

Not a huge issue, but I’m surprised this hasn’t been reported.

FWIW: This is not a public repository


  1. 1

    Posted by

    pdavidson
    on 13 Nov, 2014 12:01 AM

    pdavidson's Avatar

    BTW — what is the difference between .hgrc and mercurial.ini in a windows setting of c:\users\myUsername

    Do we need them both?

    Are they read sequentially where last read has precedence, ala css files?

    Best practice is what?

  2. Support Staff

    2

    Posted by

    Anton Gogolev
    on 13 Nov, 2014 09:20 AM

    Anton Gogolev's Avatar

    Paul,

    You’re just pasting the wrong thing and HgLab is a bit confusing
    here. To
    clone using TortoiseHg, you only need the URL part, i.e.
    everything after the hg clone substring:

    Cloning in TortoiseHg

    Storing passwords in plain-text anywhere is not exactly the best
    idea. There’s an excellent extension called Keyring,
    which ships with TortoiseHg and which can be enabled from within
    TortoiseHg Workbench in FileSettings
    Extensions by checking the «mercurial_keyring»
    checkbox.

    As for configuration files, they are very much like CSS, with
    more «specific» files overriding less «specific» ones. Here’s a
    full
    list:

    • /.hg/hgrc (per-repository)
    • %USERPROFILE%.hgrc (per-user)
    • %USERPROFILE%\Mercurial.ini (per-user)
    • %HOME%.hgrc (per-user)
    • %HOME%\Mercurial.ini (per-user)
    • \Mercurial.ini (per-installation)
    • \hgrc.d*.rc (per-installation)
    • HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial (per-installation)

    Settings from earlier paths override later ones.

    There’s no «best practice» — everyone picks whatever works in
    their specific cases. For example, a System Administrator can tweak
    Mercurial settings (via Group Policy or somesuch) in the Registry,
    you can enable the extensions you use all the time in
    Mercurial.ini from your %USERPROFILE% and
    then you can fine-tune the settings on a per-repository basis.


  3. 3

    Posted by

    pdavidson
    on 14 Nov, 2014 02:21 AM

    pdavidson's Avatar

    Well, I feel stupid. I must have stared at the documentation examples many times and modified that line in TortoiseHg over and over without cluing into the fact that it says Source

    Thanks for the keyring hint. I was considering a jump to AD to get around text passwords. Even if we are behind firewalls, bad idea. keyring is trivial to implement and very helpful.

  4. Support Staff

    4

    Posted by

    Anton Gogolev
    on 14 Nov, 2014 04:37 PM

    Anton Gogolev's Avatar

  5. Anton Gogolev closed this discussion
    on 14 Nov, 2014 04:37 PM.

  6. pdavidson re-opened this discussion
    on 17 Nov, 2014 07:53 AM


  7. 5

    Posted by

    pdavidson
    on 17 Nov, 2014 07:53 AM

    pdavidson's Avatar

    Anton:

    Regarding the per-user level usage of %USERPROFILE%\.hgrc vs %USERPROFILE%\Mercurial.ini

    I see the [auth] section that HgLab makes use of, does it matter if that is in mercurial.ini instead of .hgrc?

    I guess in other words, does HgLab search mercurial.ini for the [auth] section?

    In writing up a quick start for our coders, it would be easier to refer to dealing with just one ini file…

    Not a big deal but I am curious.

    Thanks

    — Paul Davidson

    GIS IT Lead

    (505) 768-2635 — Desk

    (505) 506-5960 — Cell

  8. Support Staff

    6

    Posted by

    Anton Gogolev
    on 28 Nov, 2014 09:23 AM

    Anton Gogolev's Avatar

    Paul,

    The .hgrc in %USERPROFILE% is there to mimic the way Unix/Linux software is

    configured (with so-called «dotfiles»), so unless your developers use both

    Windows and non-Windows platforms, there’s no need to use .hgrc and a

    single INI file will do just fine.

    HgLab, being a server-side piece of software, can’t possibly use any of the

    client-side configuration files. It can only use server-side hgrc files

    that are repository-specific to configure ACLs. See more here:

    https://hglabhq.com/documentation/user-guide/repositories#configuring-access-control

    To sum up, on Windows it’s preferable to use Mercurial.ini in %USERPROFILE%

    to configure global per-user settings.

    On Monday, November 17, 2014, pdavidson <

    [email blocked]

    <javascript:_e(%7B%7D,’cvml’,’tender2%[email blocked]’);>>

    wrote:


  9. 7

    Posted by

    pdavidson
    on 28 Nov, 2014 06:12 PM

    pdavidson's Avatar

    Thanks

    I should have caught the server side issue.

    Sent from my iPhone

  10. Anton Gogolev closed this discussion
    on 03 Jan, 2015 08:54 AM.

  11. pdavidson re-opened this discussion
    on 03 Jan, 2015 08:55 AM


  12. 8

    Posted by

    pdavidson
    on 03 Jan, 2015 08:55 AM

    pdavidson's Avatar

    I am out of the office until Jan 5th, 2015

    In the meantime, please contact:

    Bryan Ngyuen at

    [email blocked]

    (505) 289-3203

    or

    Michael Haley at

    [email blocked]

    (505) 289- 3204

    for all of your GIS IT or IR needs.

    Thank you

    Paul Davidson


  13. 9

    Posted by

    pdavidson
    on 06 Jan, 2015 02:06 AM

    pdavidson's Avatar

    Anton:

    Please delete that re-opened email above and close the discussion again.

    I was out of country and had an auto-reply system going which clearly creates issues in this type of forum :-)

    Thanks

  14. Anton Gogolev closed this discussion
    on 06 Jan, 2015 04:31 AM.

Comments are currently closed for this discussion.
You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

I’ve been using Tortoisehg for a while now, with little to no problems but have just run into the following problem:

I cannot push or commit to my main repository. I made a small change to one file in my project, committed locally with no problem, but the push to the main repo fails:

% hg --debug push "Z:\[main repo]"
pushing to Z:\[main repo]
query 1; heads
searching for changes
all remote heads known locally
listing keys for "bookmarks"
1 changesets found
list of changesets:
09d372b8d90710f2ad772dc4164fd640d6869208
adding changesets
add changeset 09d372b8d907
adding manifests
adding file changes
adding GEM.py revisions
transaction abort!
rollback completed
abort: Permission denied: Z:\[main repo]\.hg/store\data\._g_e_m.py.i-dmz4wn
[command returned code 255 Thu Mar 09 14:17:01 2017]

The main repo is on a (Windows) file server, and I am submitting from a Windows machine. I am sure that I have not run out of quota.
I have not changed permissions on the main repo, I am owner of all data and have also tried assigning myself «full control» (by default I have only read and write — not sure what the difference is, actually), to no avail.

I also tried editing the changed file in the main repo and committing there:

% hg commit --verbose "--message=GEM.py: [message]" --user [user] -- "Z:\[main repo]\GEM.py"
GEM.py
trouble committing GEM.py!
abort: Permission denied: Z:\[main repo]\.hg/store\data\._g_e_m.py.i-kbxvue
[command returned code 255 [date]]

Now, an interesting thing is that the file that Mercurial complains about does not seem to exist in the first place. There is only a file called _g_e_m.py.i in that directory. I made sure to have hidden files shown in the file manager, and I’ve also looked from Linux, just to make sure.
I also tried cloning the repo to a different location, then pushing to the new repo, but that changes nothing.

I have found this answer on this site, but I do not have a file .hg/wlock (or anything named similarly) in the repo folder.

Update:
Since was asked: The permissions for the .hg/store/data dir on the main repo are:

.hg [domain]\Domain Admins:(I)(OI)(CI)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
    [domain]\[user]:(I)(OI)(CI)(M)

On my local one, it’s:

.hg Everyone:(I)(OI)(CI)(F)

So there’s a difference. Within the .hg directory, probably as consequence of me messing with permissions while trying to solve the problem alone, there’s this:

store\data [domain]\[user]:(OI)(CI)(F)
           CCNT\Domain Admins:(I)(OI)(CI)(F)
           NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
           [domain]\[user]:(I)(OI)(CI)(M)

Yes, that’s my username, twice. I may have violated some conventions when changing permissions… I’m okay with Posix permissions but this is a bit opaque to me.

A potential clue: It’s quite possible that tortoisehg crashed before the problem appeared, or lost network connection. I was working with VPN from home, and that sort of thing can happen. So if Mercurial blocks any files/directories, there might be some block in place, though I wouldn’t know how to verify/fix that. All machines which might have been responsible for blocking the dir have rebooted since the problem appeared — except of course for the file server hosting the data.

I’ve also updated the statements above to add the --debug outputs. The random letters/numbers behind the filename changed, because I put some more changes into the file. That would indicate that it’s really not that particular file (which does not exist anyway) but the directory which mercurial attempts to write into.

If you recently cloned repository to the Windows PC, made some change and try to perform commit via TortoiseHG, you may get the following error:

Trouble committing file.

Access is denied

[Code: 255]

In order to solve it go to the Windows explorer and open properties of the repository folder. Then on Security tab click Edit and ensure that Users group has Full control rights:

After changes will be applied to all files and subfolders in the folder, error should disappear and commit should be successful.

Понравилась статья? Поделить с друзьями:
  • Torque удаление ошибок
  • Torque считать ошибки абс
  • Torque не видит ошибки
  • Torque стереть ошибку
  • Torque ошибки на сером фоне