Mercurial Permissions when using NAS - windows

I have a Mercurial repository that is located on a NAS (Buffalo TeraStation). It is mounted on a Ubuntu machine and is mapped onto a Windows 7 machine.
I have previously been able to clone, update, etc. from both the Linux machine and the Windows machine, but now am having problems. Too many changes have been made (updating versions of hg, thg, etc.) to identify a specific point where things started to fail.
I can read and write files from both machines from/to the NAS. I can use "cp" to copy entire repositories, but if I attempt to clone using hg (or thg) it fails.
When cloning an existing (in the NAS) repository to the Ubuntu machine, all of the files copy over, but the operation is aborted with the message:
abort: Operation not permitted: (repository_path)/.hg/store/.phaseroots-94sdvj
[command returned code 255 Thu Jul 30 17:39:45 2015
When cloning an exiting (in the NAS) repository to the Windows machine, the cloning hangs (with no files transferred).
I have tried various [trusted] settings to no avail.
I have tried performing the hg clone command manually and it works properly when done with "sudo". However, the cloned repository then is owned by "root".
I'm pretty sure this is a permissions problem, but have run out of ideas. Any guidance would be appreciated!

One thing can think of is support for hardlinks on the NAS you are using.
For example some of the versions of Mercurial had problems with windows shares. For more information here.

I have no explanation for the problem on the Linux machine, but the problems on the Windows machine might be caused by this exact setup (cloning from a Linux drive to a Windows machine).
Years ago, I had similar problems (although with different error messages) when pushing from my Windows machine to repositories on a shared (Linux) NAS drive - see the link for more details.
But that was over five years ago and I didn't try it anymore since then, though.

Related

is there a "safe" unix-emulator for running git on Windows?

I'm working in a large corporate enterprise where all the developer machines are Windows 7 Enterprise SP1.
I'm running major migration project from RTC to git (resulting in something like 1200 git repos). There are no Windows servers in the production environment, build or test environments - everything is either Solaris or RedHat. The solution will be rolled out to ~200 developers.
There is generally a push to use more Unix-command line tools and there are a few different alternatives on Windows such as: Cygwin, git-bash, cmder. I have avoided running a full linux VM because that introduces too many other problems (most developers don't have local admin rights and the internet proxy is a constant hassle so I don't want to make networking a bigger problem with NAT).
I've been running Cygwin (mintty 2.6.2) for the past 8 months and it's been ok until today where I hit a very concerning issue with git (v2.8.3) where git status reported a clean working directory even though multiple files and folders had been deleted in the repo. Only after I recreated a folder with the same name as one of the deleted folders did all the deleted files appear correctly with git status.
I'll explain the symptoms and what I was doing but so far I have not reproduced the issue. My suspicion is that the problem lays somewhere between the emulated linux file system and the actual windows file system. Is there any difference in the way the various emulators achieve this?
The specific problem I hit had these symptoms:
Client side:
git status showed a clean working directory
git log showed 3 commits A, B and C (commit C checked out)
The repo contents was one folder containing a file, 2 more files in the root folder, plus the .git folder with contents
git stash list was empty
git branch -a reports only master, HEAD and origin/master
Server side:
The origin contained 13 additional folders, each with one file
The origin also contained commits A, B and C
Only master branch is present
Commit A was the initial empty commit.
Commit B was where all contents was added, 14 folders and 16 files.
Commit C was another empty commit
Commit A and Commit C were both created using tools to assist with the migration. It runs two commands: "git init" and "git commit --allow-empty -m 'initial commmit'"
I could not understand how git status did not report the deleted files (I remember deleting them, but it was some days previously with multiple computer hibernates, and probably a restart or two from resuming my work)
Trying to figure out what had happened I did this:
I created a new file then ran "git add", "git commit" (creating D) and "git push."
Commit D appeared on the server with the new file. The 13 additional folders and files were still present on the server.
I ran "git pull" which returned "already up to date"
I checked the changes for every commit on the client side and on the server side and every diff was the same
I cloned a new copy of the repo and the contents matched the server with the 13 additional files and folders with the additional commit D and extra file
I then recreated a folder with the same name as one of the deleted folders and ran "git status" where finally all of the deleted files and folders were reported correctly.
I cannot explain this any other way except for a serious bug which simply makes it unsafe to use git in Cygwin. I hope the community may have some advice for me in this area and that this is phrased as a clear enough question that the mods don't flag my post.
I will do my best to try and reproduce the problem and update the issue with more info when I have some.
Edit: Update 2016-12-08
My attempts to reproduce the error have been unsuccessful. If I see it again during my work I will update this issue.
I've never seen such behaviour with Git on Cygwin. Actually currently I use Git for Windows from within Cygwin and it also works fine. I used to use the Cygwin Git, but I had the feeling that it is slower than Git for Windows, such I switched to Git for Windows used from within Cygwin and it works great.
If you at some point update the Windows boxes to Windows 10, you can also consider another option, the Windows Subsytem for Linux which is an Ubuntu based virutal Linux environment developed by MS together with Canonical. It is still in the process of getting mature and not fully usable yet in my opinion, but there you then have a natively supported virutal Linux environment where you can use apt-get and so on.
Issue you mentioned are really unexpected, and I doubt Cygwin can cause it. But you have following options
git comes with git bash, which support all major unix commands and it looks completely like unix shell. I am using git version 2.9 on windows 10 and heavily use major unix command like grep, sed & find , and they all work excellent. Even it support vi but I don't use it
git comes with git CMD, and same git commands will work on windows command prompt as they do on unix. You shouldn't need a separate emulator with this.
Though you mention you are using Windows 7, but now Windows 10 comes with native support for Unix Bash
You can use gnuwin32 but I doubt it will be better than Cygwin

SVN, can't commit changes using Tortoise for a working copy that resides on Ubuntu 12.04 machine

I've recently set up an Ubuntu 12.04 LTS machine that I am using a local media server and web server for my projects.
My sites are run from ~/public_html on Ubuntu. That folder was then mapped to my Windows 8 machine. Previously I was using XAMPP, so I copied the contents of the htdocs/ folder to ~/public_html, this includes all the svn folders.
All sites are operating normally and are accessed via 192.168.1.10/SITE_NAME
Using NetBeans 7.2, the files are directly edited from the Windows machine. When the changes are committed using Tortoise SVN, the following error is reported:
Error: Commit failed (details follow):
Error: Unable to make name in 'V:\SITE_NAME.svn\tmp'
This was after creating a new text document in the root directory of the site from the Windows machine.
Any help would be greatly appreciated as I can't figure this out since I have full privileges on the folder.
Never use TortoiseSVN Working Copies on non-local drives
Check owner and permissions for files and folders in your WC
Change workflow and use post-commit hooks (server- or TSVN-side) to deploy code to site
Additional reading

Is there a way to migrate svn without using svnadmin dump?

My linux box has unfortunately died. I can access the raw SVN repositories from a backup and I need to revive them on my Windows box (at least for the timebeing). Is there a way of migrating/importing these repositories, given that I can't run "svnadmin dump" on the linux box?
I'd suggest booting from a Linux live CD of the same distribution as your Linux server, or create a virtual machine with VMWare Player or VirtualBox and mount the filesystem, then you can do an svnadmin dump from there.
As it's no longer in use (no commits or checkouts), try copying the whole repo to your Windows box.

Mirroring folders

I want to know if there is a way to have mirror
folders with a remote machine. I see some solutions for
syncing folders with a backup drive, but I am not interested
in that. I want to sync a folder with a remote machine through
ssh. I am on OSX leopard
Ted.
Check out the rsync command line utility. You may even be able to find some good GUI applications that build on rsync. Although I haven't tested it, Grsync looks promising.

git svn rebase problem on windows

I have a problem with git.
Basically, here is what I have. I access a svn repository through git. Until now, on python files, everything worked fine.
But lately I also added some pyd, dll and lib files on the repository. THe first update went well. But then, these files have been modified and since then I can't update. These files were added from a windows computer with TortoiseSvn on the svn repository.
If I do a git svn rebase on linux, everything works fine.
If I do a git svn rebase on windows with msysgit (and also tortoisegit), I have the following error : fatal: write error: Invalid argument
If I do a git svn rebase on windows with cygwin, I have the following error : didn't find newline after blob at /usr/lib/perl5/vendor_perl/5.10/Git.pm line 916
I tried several stuff (autocrlf true/false, safecrlf true/false), adding .gitattributes file with the following line *.* -crlf -diff -merge and nothing worked.
I'm a little stuck here so any suggestion would be welcome.
Thanks in advance.
Had identical issue with Msysgit v1.7.2.3, the latest version as at 29 Sep 10, and wanted to share my findings here (Google turns up several cases, but no solutions).
Trying to do "git svn rebase" on a repo (that has this has worked on plenty of times in the past) consistently failed with a "fatal: write error: Invalid argument" after a certain number of commits. The sync would then revert to the beginning again.
I believe this is a bug in Msysgit relating to large(ish) binaries and available memory (on a Win XP SP3 system with 4GB RAM and plenty free HD space). The remote system was the DotNetNuke SVN repo on CodePlex (https://dotnetnuke.svn.codeplex.com/svn).
Initially it was choking on a 330KB "CHM" file (~212th commit, r52261). It consistently did so, even after disabling Avast AV, Google Desktop, etc and verifying that there were no other processes with locks on the repo folder. After a reboot (but opening Outlook, Dreamweaver, etc), it then was consistently and repeatedly failing on a ~15.3MB DLL (~416th commit, same revision).
Finally, after another reboot, disabling Avast, Carbonite and Google Desktop and running no other programs, the sync worked first time.
This seems to point firmly to my conclusion that it was an available memory issue, probably linked to the presence of a largish binary and large number of commits in the revision. Note that I also tried "git fsck", "git svn reset xx" and tweaking the "packSizeLimit" / "usedeltabaseoffset" config vars, without success.
I've found that the best policy for using Git on windows is to tell it to not do anything about line endings.
I don't know if that will help you recover your current git repo, but it's worth a shot.
I set:
[core]
autocrlf = false

Resources