Using hardlinks when cloning a Mercurial repository under Windows - windows

I am using Mercurial under Windows XP (using the TortoiseHg distribution) and I want to use NTFS hardlinks when cloning a repository. Out of the box Mercurial does not do this. I have read that a win32file python extension needs to be enabled. So far I have been unsuccessful in making this work (adding a win32file entry to the extensions section in mercurial.ini does not seem to work). Is there a simple way to enable it?

I think you'll need to install full Python and use the Mercurial source install. While TortiseHG's py2exe-compiled installation of Mercurial can load mercurial extensions just fine, it's my understanding that it won't let you swap out core python modules.

Related

Convert Mercurial to Git repository on Windows and without Python

For some reasons I prefer to avoid using Python.
But all I found is either Python scripts or unix specific instructions or something that doesn't have downloadable executables or unclear how to install it in windows.
Can you suggest any tool or service?
There is a plugin here for that.
Maybe just install Win-build of CLI-Mercurial or standalone TortoiseHG (plus HG-Git)?
I haven't Python per se on my box, only THG (which have Dulwich) and HG-Git anf Git-repos are pushable

Multiple versions of Git on my Windows PC?

On my Windows 8.1 PCs I have VS 2013, which has its own Git stuff baked into it. Per the "suggestion" made by the VS IDE, I installed the Git command line tools (the full Git package). This got me version 1.8.3.msysgit.0. Then I installed GitHub for Windows, which installs its own "local" version of Git (on my PC it's version 1.8.4.msysgit.0).
So now I effectively have 3 different versions of Git on my PC:
The equivalent version baked into VS 2013 (if I ask it to perform Git operations for me)
The 1.8.3 version I manually installed, with nifty Whindows shell integration so I can click on a file or folder in a repo and bring up git gui or git bash for that repo.
The 1.8.4 version baked into GitHub for Windows
And, I would assume that these Git versions will change over time as I install updates to these tools.
My question is: As I use these three different tools to fiddle with my repo, am I at risk of them not agreeing on the repo internal structure?
I just can't wrap my brain around the fact that my Windows box doesn't have a unique, single installation of Git that all three tools use. Rather, each tool has its own concept of the Git version, but I'm using all three tools on the same repository.
As I use these three different tools to fiddle with my repo, am I at risk of them not
agreeing on the repo internal structure?
No. The main internal structure (pack format) won't change so much it would become incompatible with older git 1.8 versions.
And you can have as many different version of Git on your computer: they are portable archives, that you can unzip anywhere.
The only limitation is in term of feature (like for instance, pushing to shallow repo, which is only possible since git 1.9.0)

Mercurial extensions not working in Windows 7 x64?

We are test driving Mercurial at work. We don't want to have to enter our user/pass each time we interact with a repository, so we set up the mercurial_keyring extension. We:
Installed Python 2.6.5 (32 or 64 bit, depending on the system)
Installed setuptools (for easy_install.exe)
easy_install keyring
easy_install mercurial_keyring
And then made the appropriate changes to %userprofile%/mercurial.ini in the [auth] section. It works fine on my colleague's computer (32bit xp sp3), but it does not work on my machine (Windows 7 Ultimate x64). Also noteworthy, the setuptools had to be built from source on Win 7 x64 (python setup.py bdist_wininst, then run the resulting setuptools-0.6c11.win-amd64.exe).
Using just hg.exe from the Mercurial 1.5 binary installation (the .msi), I get this error when I run hg.exe:
*** failed to import extension mercurial_keyring: No module named
mercurial_keyring
I tried to change my mercurial.ini, to specify the path to the mercurial_keyring.py file, instead of having mercurial find it (since it's in the PYTHONPATH).
Old:
[extensions]
mercurial_keyring =
New:
[extensions] mercurial_keyring =
c:/mercurial/extensions/mercurial_keyring.py
The error changes to:
abort: could not import module
keyring!
So while providing the path to the mercurial_keyring extension works, the dependent keyring module still cannot be found.
After further investigation, it appears that NO extensions work. They all produce the error:
*** failed to import extension [extension name]: No module named
[module name]
It appears that when running hg.exe, it is not aware of PYTHONPATH. I have tried:
Python 2.6.5 32 bit
Python 2.6.5 64 bit
Building Mercurial 1.5 from source with MinGW
Building Mercurial 1.5 from source with MSVC9
Using hg.exe from the 1.5 binary dist (.msi)
Using the hg.py in c:\python26\scripts when building from source
Various configurations in %userprofile%/mercurial.ini
Using setuptools (easy_install.exe) to install keyring and mercurial_keyring
Building keyring and mercurial_keyring from source (python setup.py bdist_wininst)
Nothing works. The closest I've got is using hg.py when building from source. It at least doesn't give me errors, and actually creates %userprofile%/wincrypto_pass.cfg when I enter my credentials. But on subsequent requests, it doesn't enter the credentials automatically. It prompts me for them again.
Interestingly, TortoiseHG is using the keyring. I just can't get it to work on the command line. I think something is going on with Win 7 x64 that is preventing mercurial (hg.exe) from seeing the PYTHONPATH, so it can't find any of the installed modules.
Does anyone have extensions working in Win 7 x64? Specifically with the binary installation of mercurial (not hg.py)?
UPDATE
I've found a suitable work around for now. Since TortoiseHG does work with mercurial_keyring, I've simply changed my PATH setup to include the tortoiseHG folder, but not c:\mercurial. Now when I type "hg" at the command line, it's using the hg.exe in the tortoiseHG folder, which works fine. Just the same, this is still a problem with mercurial extensions on Win 7 x64. Answers welcome.
Answering my own question with my previous update, since there are no other takers yet.
Suitable workaround: Since TortoiseHG does work with mercurial_keyring, I've simply changed my PATH to include the tortoiseHG folder, and exclude c:\mercurial. Now when I type "hg" at the command line, it's using the hg.exe in the tortoiseHG folder, which works fine with the keyring.
I'm using:
on Windows Server 2008 SP2 x86:
Python 2.6.5 x86
Mercurial 1.5.1 x86
TortoiseHg 1.0.1 x86
on Windows Server 2008 R2:
Python 2.6.5 x86
Mercurial 1.5.1 x86
TortoiseHg 1.0.1 x64
On both setups, all configured extensions are loaded without errors.
All tools are installed using the installers provided on their sites. Mercurial appears before TortoiseHg in PATH. I'm using a common configuration file ~/.hgrc for both tools, and a Mercurial.ini file in TortoiseHg installation folder that is loading just the mercurial_keyring extension.
On the command line I have to input the password every time it's needed, but in TortoiseHg the keyring extensions it's fully working.
From the Keyring Extension page on the Mercurial wiki:
If you are on Windows, we recommend you use TortoiseHg. THG ships with Windows specific keyring backends, without which the mercurial-keyring extension cannot function properly on Windows.
UPDATE http://asimilatorul.com/adapter/post/using-mercurial_keyring-extension-with-mercurial-on-windows/
You can copy the required files from TortoiseHg's library.zip into Mercurial's library.zip:
hgext\mercurial_keyring.pyo
keyring__init__.pyo
keyring\backend.pyo
keyring\core.pyo
win32_crypto.pyd
The extension page states that TortoiseHG has some additional components to make it work on Windows and that it doesn't work properly without them. It sounds like the workaround of referencing the TortoiseHG version may be the easiest way to get it working on Windows.

Can we use git-cvs on windows?

I'm comfortable using git, and I prefer it very much over CVS. Unfortunately, in our company, we have to use CVS as a version control system. I was wondering if there was anyway to use git locally while committing to the CVS repo, and I was elated when I found this SO question. Unfortunately, it does not seem to work on Windows. I have Git For Windows (mysysgit) installed on my computer, and when I type git cvs or git cvsimport in the terminal it says "not a git command". Is there anyway I can use this functionality on windows?
Use Cygwin git instead of msysgit, it has this and other functions, like git daemon.
Or you can implement this feature and contribute it to msysgit.
I make that methodology work on Windows, but since our CVS server is Linux I do my export to CVS on that server, and then clone to my Windows machine. I push back through a staging repository also located on the Linux server.

How do I manually install an old cygwin package?

A project I am working on requires an old version of SLAPD (the LDAP
server) and must run on Windows, hence I am using cygwin packages:
I've found a binary package of slapd version I need 2.2.x here:
http://www.mirrorservice.org/sites/sourceware.org/pub/cygwin/release/...
How do I manually install it in cygwin? It does not seem to be a package-manager file format (like an RPM or a Deb), but is there a tool to install it for me?
FYI, I'm operating behind a corporate firewall that prevents me from viewing the main cygwin site (including the documentation), so please nobody tell me to RTFM - I wish I could!
Thanks
If you need an older version, the Cygwin time machine might help. To use it, I had to invoke setup.exe from the command line, giving it the --no-verify/-X option and it still wouldn't let me downgrade the "cygwin" package itself but at least it is, albeit very slowly, allowing me to install the version I wanted to test as a parallel installation.
If you are using the cygwin package installer to install this package, usually if you select to view the full info and scroll to the package you need you will see some info about the version.
Now if you click on the version number you will see that it changes from the oldest in the repository to the current. If your repository has the version you need then just finish the wizard.
Some cygwin mirrors keep old package files, for example, http://mirror.isoc.org.il/pub/cygwin/
You can use Sonatype nexus to mirror an existing cygwin repository, but provide your own setup.ini .
Copy the already downloaded repo content to c:\progs\nexus\sonatype-work\nexus\storage\mirror.isoc.org.il-pub-cygwin\
Put your own setup.ini and setup.bz2 there.
Start setup.exe with --no-verify
Paste
http://localhost:8081/nexus/content/repositories/mirror.isoc.org.il-pub-cygwin/
into the mirror selection box and click "Add"

Resources