I have installed the latest version of watchman, which can be found here:
/usr/local/bin/watchman
I performed the Install Recommended Packages on Startup and I watched them install after restarting.
This is a fresh new install of Atom and Nuclide with the latest version of everything.
I have a test project with files added to the Mercurial repository. The repository .hg directory sits at the root of the project. When I open a Diff View into a file, Nuclide picks up the previous Mercurial version of that file just fine as I make edits and it shows the comparison between the two. Previous version on the left is shown. So I know that Atom-Nuclide is able to interact with the Mercurial repository.
However, nothing else seems to be working for Mercurial support.
When I select "Toggle Blame" on the same file where Diff View is working, I get this message: "Failed to fetch blame to display. The file is empty or untracked or the repository cannot be reached."
The File Tree Highlighting does not work. No colors on any of the files in any of their mercurial states.
The colored Line Modification Notifications do not show inside of the Atom gutter.
The Added and Removed Lines feature is not showing in the status bar.
These features in Atom-Nuclide are the reason why I am interested in trying out Mercurial instead of Git and are big reasons for trying this IDE in general.
The same problem was reproduced on a different distro. I can't be the only one who bumps into this. No business can safely rely on a development environment where the level of community interest outside of FB cannot support an attempt to claim a Stack Overflow bounty on a question like this. The solution is to wait for better type support and type checking to come to PHP. Numerous RFCs exist to do exactly that and other IDEs will take advantage of this in future versions of PHP.
Related
Some years ago, Mercurial | TortoiseHG could exchange data bidirectionally easy with at least 2 Big Brothers:
Subversion, using HGSubversion
Git, using HG-Git
Current (6.0 versions of family) state - the ordinary users have none:
hg-subversion is broken (extension can't be loaded), bundled with THG (Mercurial ???) extension not updated since 2019 hgsubversion: 6a6ce9d9da35 2019-04-19 (extraction from my TortoiseHg\extension-versions.txt), external SVN-bindings exist only for Python 2.7 (while py3-movement inside Mercurial is live and active)
hg-git got some big troubles, starting from THG 4.9 (manual patching of library.zip was required), on 6 version the situation has gotten better (no patching), but still unsatisfactory for the common user - installing Python 2.7 (for single-user) and using pip isn't The Right Way (tm)
Are there any comments, additions, clarifications, recommendations on how to do it (if what I am doing is wrong)?
Addition after some testing: special verson tortoisehg-6.0hggit-x64.msi from Matt Harbison at least allow using hg-git with ssh-transport (not http yet) and can be recommended for every-day usage by ordinary user.
So, as a current maintainer of hg-git and former contributor to hgsubversion, I think I can provide some context here.
Regarding hgsubversion, the short answer that it is either dead or — at best — extremely dormant. Personally, I have not interacted with a Subversion repository in years, and that's a common experience. No-one has been sufficiently motivated to fix bugs, keep it working, and — last, but not least — make it work with Python 3.
For hg-git, a period of semi-dormant state meant that the TortoiseHg maintainers stopped bundling it. We now keep up with Mercurial releases, and I've requested that they reverse that decision. I believe they bundle Dulwich, but as I don't use Windows, I can't say for sure. That said, it's quite reasonable to want to use hg-git with TortoiseHg, and if you run into any specific issues, I'd suggest you file a bug with them — or perhaps add a comment to the bug I linked earlier.
Generally speaking, you should be able to use 0.10.x version of hg-git with most versions of TortoiseHg, as I believe they bundle Dulwich. In that case, enabling the extension should be as simple as:
hg clone -u 0.10.x http://foss.heptapod.net/mercurial/hg-git /path/to/repo
And then adding the following to your .hgrc:
[extensions]
hggit = /path/to/repo/hggit
Once TortoiseHg moves to Python 3.x, the default branch of hg-git will work with it again.
EDIT: I was wrong; they don't bundle Dulwich, it seems. On the bug for this, one of the maintainers posted a link to a packaged installer that includes hg-git & Dulwich. The next release, 6.1, should fix this. Please consider testing the installer, and report to the TortoiseHg maintainers whether it works as expected.
EDIT²: Please note that only SSH works with that installer, as they ran into some issues bundling urllib3, which is necessary for HTTP support.
TortoiseHG 6.2
Bundled hg-git works (at least with GitHub), but for now only for https:// repos:
old worked ssh-access failed with complaining about my keys
With the new keypair (still RSA) and PageAnt-x64 (for THG-x64) I got both access-methods in game
I upgraded to Tortoise 3.6.3 yesterday and now I am prompted every time I pull or push a repo. The keyring is set properly, and my user name is in the url.
Any ideas on what may be wrong? Did 3.6.3 break keyring?
Issue 4401 "mercurial_keyring always asks for user/password" from time of 3.6.2 closed as pure extension-specific and contains solution: don't use username in URL anymore
Here is what to put into .hg/hgrc:
[auth]
default.username=myname
default.prefix=http://myrepo
A good way to debug issues like this is to run merciural from the command line with the debug flag, as in:
hg pull --debug
This will clearly indicate if there are problems getting the repo, user name, and password.
UPDATE: A new version of TortoiseHG has been released (3.8.3 at the time of writing) and fixes this issue: upgrading to latest version should be enough.
I had this exact same problem and found the following investigation article to be quite helpful to better understand what't going on (I'm not the author, BTW).
To cut it short, it seems a bug of the mercurial_keyring extension v1.0.1, introduced in TortoiseHG 3.6.2, which also appears to be fixed in v1.1.1.
If you're into Python compiling, it should be possible to upgrade it manually into TortoiseHG by getting it from its official bitbucket repo, compile it and manually place it into TortoiseHG's /lib/library.zip file (backup it beforehand might be wise): if you're not, you have 2 options:
1) clone the bitbucket repo to your HDD and then configure your Mercurial installation to use the new version of that extension module by writing the following in your C:\Users\USERNAME\mercurial.ini file (which was what I did):
[extensions]
mercurial_keyring = /path/to/mercurial_keyring/mercurial_keyring.py
(Notice: you might also have to put the path in your PATH or PYTHONPATH env variable, depending if you already have Python and/or Mercurial installed on your machine).
2) wait for the next TortoiseHG release that will contain the updated version.
Heey,
I got a little problem. The current Monogame 3.2 build available hasn't got a working template for Windows Phone 8. This will result into a black screen and a non working app. So I went onto their git hub and found the issue https://github.com/mono/MonoGame/pull/2089 and someone who fixed it and posted a Pull request.
The problem now is I have close to zero experience with building my own version or editing project template files. I got some common knowledge and started to delve into this all and already tried copying the template files to my visual studio files and building projects and throwing around the new .DLL but it all doesn't want to work properly. I started to work with the older template but I need the new version due to proper support for landscape in windows phone 8 that we need to utilize for our game.
Now is my question if someone knows the right/proper way to do this. A short summing up from what to copy where will do.
Thanks in advance.
Okay it took me some time but I figured out what to copy,build,set and run.
You download the .Zip or make a pull with your Github into an empty folder and when finished extract it.
In the map open the MonoGame.Framework or MonoGame.Framework.”your
target platform” which will startup visual studio.
Build the solution/project (don’t forget to build in ARM, x86 and
x64 if enabled and needed) and navigate to “Extracted
folder”/MonoGame.Framework/bin/”your targeted platform” at the same
time open a new explorer and navigate to your MonoGame installation
by default C:\Program Files (x86)\MonoGame\v3.0
Navigate in your extracted folder to your targeted platform and
build and copy the MonoGame.Framework.dll to the opposing C:\Program
Files (x86)\MonoGame\v3.0\Assemblies\”targeted platform”\”build”
Rebuild your Project/Solution
Gratz you now updated your MonoGame :)
This could fix your problem but it’s possible that you still get an error when initializing your app on your phone or emulator DXGI related.
If this occurs then follow these steps. The problem lies probably by your SharpDX.WP8.dll how to fix this? In my case download and install the newest SharpDX http://sharpdx.org/download/ you could also look further how to only download the SharpDX.WP8.dll & .winmd!
Navigate to your SharpDX install (by default C:\Program Files
(x86)\SharpDX) navigate further to
Bin\DirectX11_1-“platform”-“build”\ and copy the SharpDX.WP8.dll and
.winmd to C:\Program Files
(x86)\MonoGame\v3.0\Assemblies\WindowsPhone\”build”
Rebuild your Project/Solution (if this still doesn't work you may
need to manually add the references again to SharpDX.WP8.winmd for
both builds)
So if it’s alright this should fix most issues but there is one left. Between MonoGame 3.0.x and 3.2 the project template of a windows phone game has changed but this didn't went well in the code. So we’re now going to update the project template of our Visual Studio.
Go back to your extracted Monogame map and head into the folder
“ProjectTemplates”\”your visual studio version”\WindowsPhone
Select all files and create a .Zip (could be done by the integrated
windows option “Send To”) make sure when you open the .Zip you will
immediately see all the files and they aren't nested into a folder
inside the .Zip
Navigate to C:\Users\”your PC name”\Documents\Visual Studio
201X\Templates\ProjectTemplates\Visual C#\MonoGame and copy your
just created .Zip and overwrite the existing file.
You may have to follow these steps if you use different version of Visual Studio because of the lack of support for XNA inside VS2013.
Now you should've fixed any possible problem. If your project still gives errors try to recreate a new one (this would now use the new updated template you just copy pasted and would work) If this still doesn't work than please post what goes wrong but this all should do! These instructions should also work for all other platforms (at least which you could build of course)
Pretty easy to do pull it in to your own version.
Follow these steps:
Fork the Monogame repository
Clone your version to your local machine
Find the repository of the fixed code.
In a command prompt, move to your MonoGame folder, and pull the changes in using this line on your machine. (the branch is most likely master)
git pull http://github.com/other/repo branch_name
Once you have the pull request pulled into your local branch, just build it using Visual Studio.
You can also follow these steps if you think you'll be doing this often.
https://help.github.com/articles/syncing-a-fork
For some reason MrME, I couldn't get your solution to work because of some missing SharpDX reference which REFUSED to be added manually. While your solution may be valid I would like to present an alternative if you have the patience to transfer the code to a Monogame 3.2 project and are still getting the black screen:
Set the DrawingSurface to a DrawingSurfaceBackgroundGrid in the GamePage.xaml. Full details are found in the commented explanation at the bottom of the GamePage.xaml file.
Source: https://github.com/mono/MonoGame/issues/2081
I am using VisualHG inside Visual Studio. On occasion when pulling (with Fetch) I get this error message:
[Errno 13] C:\inetpub\Websites\SomeProject.csproj: The process cannot access the file because it is being used by another process
This in turn makes a mess of my repository causing me to have to delete everything and pull again. Is there anything I can do to prevent this? It seems this issue never happens when pulling from TortoiseHG or from the command line, only when the project is opened in Visual Studio and pulling with VisualHG.
We're seeing something very similar on a machine here with TortoiseHg 2.0.4 and VS2008. It looks like Visual Studio it briefly locking the file as it detects a file modification event, and this is causing Hg to fail. We're seeing this with both TortoiseHg and the command-line client.
Whilst it's pretty frustrating when it happens during a pull, it also happens during a merge too, which can be pretty catastrophic.
It may be the only thing you can do is to not have Visual Studio open when you fetch. It's not the pull part of fetch that's causing it, but the update. Visual Studio seems to have a lock on your project file and won't let Mercurial change it while it's open.
You didn't specify, however, if the project was open when you used fetch through TortoiseHG or the commandline. You could also try just pulling and updating separately rather than using fetch.
Edit: It could also be the TortoiseHg version. I tried doing an update to a different revision earlier with an open project and Visual Studio 2008 just wanted to reload it (no file lock error), but I'm using TortoiseHg 2.0.5. You can always go back to 1.1.* if you don't like it or it doesn't work.
We have seen the same issue with file locking with Mercurial and VS2008, but unrelated to the .csproj files. We don't even version control our project files as they are generated by cmake and we version control our cmake files instead.
This problem has caused me to lose a days worth of work in one case and caused improper merges in other cases in that older files were overwriting newer files.
I was using the fetch extension when these things happened.
Z:>hg --version Mercurial Distributed SCM (version 1.9.2) (see
http://mercurial.selenic.com for more information)
Copyright (C) 2005-2011 Matt Mackall and others This is free software;
see the source for copying conditions. There is NO warranty; not even
for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I followed the answer from this posting:
How to use Mercurial, Maven and Eclipse together?
But the "Check out Maven Projects from SCM" still does not allow me to use Mercurial SCM.
The only option I get is "svn" in the dropdown, and even if I ignore the drop down and enter in "scm:hg:http://myMercurialRepoURL"
I'm using:
Eclipse 3.6.1
m2eclipse 0.12 from http://m2eclipse.sonatype.org/sites/m2e
"Maven SCM handler for Subclipse" 0.12.0 from m2eclipse extra's site (sorry, I would give the URL, but my new account doesn't have enough rep)
MercurialEclipse 1.8.1 from http://cbes.javaforge.com/update
And I've uninstalled, and reinstall those plugins in that order.
I'm able to use Maven in projects, and use Mercurial separately in Eclipse - it's just this one Wizard that seems to be broken, which leads me to believe that if I try to Materialize an Artifact from a Mercurial repo that it will also fail.
Has anyone had any luck with this Wizard? Perhaps on earlier versions? Is this a new bug?
Thanks
As far my search went, I didn't get to find a suitable connector for mercurial and m2eclipse (in terms of only using IDE). However, I did an experiment wherein I cloned a copy of the source from outside the IDE. (via TortoiseHg specifically)
Afterwards, assuming you have already m2e installed in Eclipse:
Go to File > import > maven > existing maven projects, then select the folder where you've originally pulled/cloned your source code.
I believe by doing so, you'll see the m2e commands in the project's context menu (via run as), and effective use mercurial commands. (via team context menu)
At least for now, this is better not using m2e and mercurial at the same time.
If anyone has a more streamlined approach, I'm also curious. :D