My Cygwin SVN client changed behavior regarding Windows ACL between version 1.6.17 and 1.7.4.
[ UPDATE: SVN 1.7.4 and 1.6.17 have the same behaviour actually. The problem lies elsewhere. What I didn't get is the point where it stopped working, probably a Cygwin update. ]
[ UPDATE: The Cygwin-built SVN client actually honors the svn:executable keyword by setting the executable ACL bit for the current user. The mention "has not effect under Windows" in the SVN book has to be taken with caution. ]
Running a check-out with 1.7.4 sets all extracted files to read-only for the current user. For instance, and that's what is annoying in my specific case, it does not set the execute flag for batches. In the file properties, the Security tab ticks Read for Everyone, and Read/Write for the current user.
Running a check-out with 1.6.17 does not show this behavior. Files are checked out with user-friendly rights, and batches can be executed. In the file properties, the Security tab ticks Read & execute/Read for Everyone, and Modify/Read & execute/Read/Write for the current user, which is what I'd expect from a check-out. That check-out is part of a scripted process, so the environment is the same in both test scenarii.
I found no mention of that behavior in svn tickets, and had no luck searching. Most of the results relate to server-side configuration.
I'm no ACL/NTFS expert, I did read the Cygwin posix/windows article at http://cygwin.com/cygwin-ug-net/ntsec.html, but that did not clarify the difference.
I tried the svn:executable keyword, but as expected this has no effect under Windows.
The same difference happens under Windows 7 or under XP.
I noted that TortoiseSVN 1.7.6 (built against "native" SVN 1.7.4) runs the check-out correctly.
I have the default fresh-install /etc/fstab, which is empty, and no /etc/fstab.d config.
It's not that I'm unhappy with 1.6.17, but some of the features in 1.7.4 are interesting.
How do I solve that weird access rights issue?
Well, the solution was to rebuild /etc/passwd and /etc/group using mkpasswd and mkgroup.
However, rolling the changes to those files back does not revert the configuration in a state that triggers the issue. Possibly rebuilding them and running the check-out again had an impact on the SVN tool itself, but I have no idea why and how.
EDIT Nope, problem not solved.
Ultimately, this was solved by find'ing and chmod'ing files deemed executable:
sh - c "find %MYDIR% -name '*.bat *.sh *.exe *.com *.cmd' -exec chmod u+x {} \;"
What I certainly missed because of a lack of time to investigate is that svn:executable should actually be handled by the Cygwin-built SVN to add the correct permission flag. I'll have to check that soon.
[ UPDATE: The Cygwin-built SVN client honors svn:executable, so this is the way to solve the issue. ]
Related
I've been using git on windows for years without any major issue.
However, it's been some time now that I believe I have something that tempers with my local git repositories and from time to time flags my modified files as assume-unchanged to the point I have an alias that runs all my repo files and update-index --really-refresh --no-assume-unchanged each and every one of them, and I use it nearly before every git status. But this is no way to live! :P
I had removed ConEmu from my machine in hope this might help, but didn't get any results (mind, I should probably restart my machine before). I doubt VS code has anything to do with it. I'm at lost tbh. Is there any git config value that may cause this?
Has anyone experienced a similar issue and found the evil forces that are behind this Machiavellian mechanism? I wish to name and shame it throughout the universe...
Seriously though, any help would be highly appreciated.
I had a similar problem, but on Linux. The answer from OP about git config didn't work for me but got me looking in the right direction.
The git config option core.fsmonitor was set to true (carried over from my Windows config where this was an experimental option that improved performance). On my Linux system, this causes basically no file system changes to be detected by git. Now that I've removed it, everything works just fine.
Hope this helps someone else with the same issue.
From your comment : something (some script or some other process) is setting the assume-unchanged flag on each of your files.
You may look into your .git/hooks directory (also check git config core.hooksPath to see if you have a custom hooks directory configured), or some other script/task that would pass on all the files in your repo.
If you really don't have a clue about what might be causing this : use grep -e "assume-unchanged" -r . (to try to spot a script which would run update-index --assume-unchanged), first in your repo, then in your home dir, in last resort from / ...
Ok, so after messing around with vs code, resharper and sublime text (uninstalling everything, deleting leftovers, restarting the machine and so on)- nothing was coming up as the reason behind this weird behaviour.
And then I commented out all of my gitconfig file- and the behaviour was gone. It then took me no time to figure out the reason behind this behaviour was the following configuration that was set to true:
core.ignoreStat
I have no idea how and when did it sneak into my gitconfig file and got set to true, but hopefully this will help others who may experience this.
I'm aware of the fact that this issue has been discussed in several questions but no answer solved my specific issue.
I have installed Git bash and Maven and I'm trying to execute Maven with Git bash. It aborts with the mentioned error.
My system environment:
Windows 7
Git 2.13.3
Maven 3.5.0
The required user variables:
HOME=%HOMEPATH%
M3_HOME=%MAVEN_HOME%
MAVEN_HOME=path-with-no-blanks
Path=%MAVEN_HOME%\bin
Maven works fine on Windows command prompt and Cygwin. Only MINGW-based Git bash fails.
I examined the bash script mvn under: C:\path\to\maven\bin
By setting log outputs and by checking when MAVEN_HOME value gets lost I found out that it gets cleared by these statements (even JAVA_HOME):
# For MinGW, ensure paths are in Unix format before anything is touched !!!HERE MAVEN_HOME value is getting lost!!!
if $mingw ; then
[ -n "$MAVEN_HOME" ] &&
MAVEN_HOME=`(cd "$MAVEN_HOME"; pwd)`
[ -n "$JAVA_HOME" ] &&
JAVA_HOME=`(cd "$JAVA_HOME"; pwd)`
# TODO classpath?
fi
On another Windows machine (different version of Maven and Git) the same lines are a bit different:
M2_HOME="`(cd "$MAVEN_HOME"; pwd)`"
instead of:
MAVEN_HOME=`(cd "$MAVEN_HOME"; pwd)`
First, I thought it's due to the kind of quotation characters. But the working Windows machine even runs well with the new script from my failing Windows machine. I also tried to install the old Git or an older Maven - nothing helps.
Why does the mentioned bash script line clears the MAVEN_HOME variable?
I was getting the exact same error for a while until I realized that it was being cause by my antivirus (Comodo). Git bash would not work properly even if I had exited/disabled Comodo.
So if you have Comodo, try following these steps to fix the error (if you don't then maybe try performing something similar with whatever antivirus/firewall you are using):
Comodo->Settings->File Rating-> Add Folder (Git Folder). This ended up adding over 5000 trusted files (but it helped fix the issue).
Comodo->Settings->Advanced Protection->Miscellaneous-> and find the checkmark "Don't detect shellcode injections in...". I added the entire Git Folder to shellcode injections.
I set the git folder to "ignore" in Comodo->Settings->containment->"Auto-containment"
I'll add that I'm not sure if all of the steps are required, so feel free to perform them one by one and see which helps.
Experiencing exactly the same problem on a Windows 7 machine. Happened overnight with no version change in git/mingw64, maven or java.
The first test you can consider is a PATH issue (the OP actually mention an incorrect Path=%MAVEN_HOME%\bin)
Use, for testing, a simplified PATH in a CMD session (so just limited to that session)
set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%MAVEN_HOME%\bin;%PATH%
set PATH=%JAVA_HOME%\bin;%MAVEN_HOME%\bin;%PATH%
You can adapt the same idea in your .bashrc, if you want a similar $PATH in your bash session, by typing bash in the CMD with a simplified PATH.
Then; in that context, you can check again if the issue persists.
We're using svn for version control on our Mac. Its working cool. But the only problem is we're multiple devs developing together and everyone can see any file changes status inside their Xcode ( attributes next to the file ) in their Xcode except me. How to resolve this?
This is what I want (see "M" next to the file name),
Even Xcode Source Control Menu is showing no changes.
I'm not sure if there's anything to set here?
I have checkout the code again and again, but still the problem persist.
I'm not sure, why this "Working Copies" menu "iOS" is disabled? Its enabled on other machine.
Any help would be highly appreciated.
I also encountered this problem, the following is my solution, hope I can help you.
Start the terminal, enter the code in the folder.
Type the command - svn status.
The output will be similar to this
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/Users/chao/svn/project'
is too old (format 29) to work with client version '1.9.4 (r1740329)' (expects
format 31). You need to upgrade the working copy first.
Type the command - svn upgrade.
The problem is resolved,I wish you good luck.
SVN can define status of working copy files and directories comparing your local files with the current repository located on the remote SVN server.
I believe that checking "Refresh server status automatically" will do the job.
You can say this is true when your local files will have attributes aside (U, M etc)
Having no luck, you may run the command line tool, which is usually more verbose. More details here: https://stackoverflow.com/a/19922150/195812
I am trying to set up subversion on windows. I followed this blog (http://blog.codinghorror.com/setting-up-subversion-on-windows/) and did the setup as instructed, it was successfully installed i think, but i am stuck somewhere in-between while testing if it is working or not
After doing this :
set SVN_EDITOR=c:windowssystem32notepad.exe
svn mkdir svn://localhost/myproject
it opens up notepad and i modified and saved it and it was suppose to ask for credentials and all but it is showing some other messages.
I am not sure how to make it working. Am i doing something wrong ?
This can happen if you didn't save the commit message in notepad.exe. Press Ctrl+S and close Notepad. You should see authentication prompt after this step. If the server allows anonymous access then the commit should start without any additional actions.
I found the solution. This was down to a version conflict. I have Tortoise version 1.8 installed on my PC and I was downloading version 1.6 of Subversion.
Solution:
Subversion: SVN E160043. Expected FS format between '1' and '4
svnadmin create --compatible-version 1.6 PATHNAME
Fixed my problem.
As far as I know you have to save your message correctly. If you have to work with Windows/OSX parallely, be aware that you have to use different Shortcuts(Windows: Crtl+S OSX: cmd + S). Otherwise it should work, if the server allow access (as you're hopefully the admin)
I'm trying to set up a scheduled Subversion commit from Windows Server 2003 machine over SVN+SSH as a task. I'd like the commit script to be executed as SYSTEM-user. So I'm guessing, for that to work I need to check-out the repository as SYSTEM, too - but am unable to achieve it so far.
I'm already able to achieve the above with my own user over SSH. I've done the following:
I added a [tunnels] entity in my local subversion configuration:
ssh = plink.exe -i "C:/Keys/my_key.ppk"
Added the key to the authorized_keys file on the server running Subversion
I checked out the repository with a script as below:
svn co svn+ssh://user#server/path/to/repo/ C:\Local\Project\Path
I'd now like to reproduce the above steps for SYSTEM user, to be able to run a scheduled commit later. The problem I'm facing is I don't know how to check out the repository as SYSTEM, because:
I don't know the syntax to use to check out a repository as SYSTEM
I don't know where the global (or SYSTEM's) Subversion config is stored on a Windows Server 2003. I've already tried: C:\Documents and Settings\Default User\Application Data\Subversion and C:\Documents and Settings\Administrator\Application Data\Subversion, but without success.
I also read somewhere I possibly could use svn switch for what I want, but wouldn't know how to svn switch as SYSTEM. I also considered writing scripts for svn check-out or switch and running them as SYSTEM, but then I still need global SVN config to add my_key.ppk, too.
I hope the above description is clear enough. I've been struggling with it for a long time now and am having problems summarizing it myself. Any hints appreciated.
As a side, that doesn't seem to be totally off-topic: https://serverfault.com/q/9325/122307
This is not a real answer to your question, yet it might solve your problem: Why not use svn <command> --config-dir ARG or svn <command> --config-option ARG?
You could specify the config file/option like this, thus being able to set [tunnels].
#cxxl really answered on question, when mentioned --config-dir. I'll just try to shed some light on problem
I'm guessing, for that to work I need to check-out the repository as SYSTEM
Wrong and bad guessing, because stored locally user's auth data doesn't used in case of SSH-auth, for ssh remote authentication performed. Per-user auth-dir
\%AppData%\Subversion\auth>dir /W
...
[svn.simple] [svn.ssl.client-passphrase]
[svn.ssl.server] [svn.username]
...
contain stored credentials only for http|https|svn and cert-based client authentication, and nothing for ssh-related repositories
I.e your executed under LSA script must be able to
* read Working Copy files (checkouted under any other real local user), maybe write (can't recall requirement for .svn dir permissions)
* read and, thus, use predefined and fine-tuned Subversion's config files (tunnel section), which can be config of any other user
PS: swn switch change linked URL of repository for Working Copy and have nothing common with users