we are using tortoisegit 2.11.0 and the PATH variable at windows is pointing to the standard installation path at c:\Program Fles..... Can't change this because of system rights!
Now, our git.exe to use is located on a network storage! So I changed the path to the git.exe in the options dialog to the network location.
Everything fine!
But from time to time the path suddenly changed to the standard git-installation path?
The problem occures if the network storage is not avaliable or the tortoise client ist started a little bit before the netword drive is connected!
So how can I set the path to git.exe to an invariable destination that tortoise will not change it automatically back if the source is not available?
Is there a parameter in the .gitconfig or somewhat?
Thanks for your help!
As of TortoiseGit 2.13 there is no way to disable the Git.exe detection mechanism.
It tries to find a git.exe on the path and looks for the installation path of the Git for Windows bundle if not Git.exe is configured yet.
The path is stored in registry, maybe you can create a .reg file to set it back (HKEY_CURRENT_USER\SOFTWARE\TortoiseGit; MSysGit).
It might help not to have another git installation available on the system.
I have more than 40 folders are added into search PATH on my Windows 7 machine. I used to put Python environment in the User PATH. Yesterday the system can't find python.exe suddenly... I tried to move the folder path to System PATH and the problem solved.
But today, I installed Tex live package on my machine. By default, the path of C:\texlive\2015\bin\win32 was added to User PATH. System can't find any file under this folder. Then I tied to move C:\texlive\2015\bin\win32 to the end of System PATH. System still can't find any file in this folder... Finally, I tried to paste C:\texlive\2015\bin\win32 at the beginning of System PATH, than it works (all the files in this folder can be searched).
can some one explain why I put the path to the end it doesn't work but when I put the path at the beginning it works? I prefer to put some path to User PATH, I don't know why now them can't be searched?
Somehow, and I have no idea how, I have managed to create a folder in our SVN repo called "C:"
This is preventing me from updating my working copy - I get the error
'.' is not valid as filename in directory 'C:\SVN'
All the actual files/folders are all greenflagged, indicating everything is up to date, the bolded line indicating my working copy revision in the log is not at the top - which is very annoying - and may happen to other developers if I don't' fix the repo.
The folder as displayed in the repo browser is empty. When I try to delete the folder in the Tortoise repo browser I get
Unable to connect to a repository at URL
'svn://10.151.0.107/svn_repository/source/C:'
Can't open file '\svn_repository\source\C:\format': The filename, directory
name, or volume label syntax is incorrect.
How can I delete this folder?
The answer is provided at SuperUser at https://superuser.com/questions/165395/how-to-delete-invalid-files-with-colon-in-their-name-under-windows
It could be that you've created the path using Subversion client in the past. Subversion allows special characters in the repository while Windows does not. I can advise removing this C: directory from the latest revision using the command:
svn del "svn://10.151.0.107/svn_repository/source/C:" -m "Removed folder with invalid name"
I'm having trouble while building my WPF solution. Everytime I try to build it, I get this error message:
Unknown build error, 'The specified path, file name, or both are too
long. The fully qualified file name must be less than 260 characters,
and the directory name must be less than 248 characters.'
Someone can help me? I've already verified all the fields and their extension paths are ok. Can this be a problem with the TortoiseSVN or something like this? I recently added a folder to my solution, can be something with this?
This is a well-known restriction in the Windows win32 api. The directory in which you stored your project is nested too deep. The full path name of a file cannot contain more than 259 characters. Beyond this, lots of C code that uses MAX_PATH starts failing due to buffer overflows.
Move your solution to another directory, one that's closer to the root.
I had a similar issue where the compiler reported that there was a problem with the file ASPNETCOMPILER. The actual issue was that the solution contained a node_modules folder, and this folder can contain very lengthy paths, and it looks like the compiler can't handle this.
Windows 8.1 and 10 have an option to increase the Win32 path limit:
Open Group Policy Editor (Press Windows+R and type gpedit.msc and hit Enter)
From the Group Policy Editor window, navigate to the following node: Local Computer Policy\Computer Configuration\Administrative Templates\System\Filesystem
Doubleclick on Enable Win32 long paths option and enable it.
This may allow you to temporarily move the problem folder out of the build, which may allow you to successfully build, then you may be able to add the folder back into the solution without affecting anything.
See here for additional reference - https://www.microfocus.com/documentation/filr/filr-4/filr-desktop/t47bx2ogpfz7.html
There is registry approach which can be used at least for Windows 10:
Value of the parameter HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) should be set to 1.
You don't even need top restart anything (IDE or PC).
This problem is caused by the restriction of Windows OS about handling long path greater than length 260. The solution of this problem for VS2019 is pretty straight-forward. But, for VS2017 users, we can use a workaround to solve the problem.
VS 2019
Open run window (windows-key + r), then type regedit and hit enter.
On the address bar of Registry Editor, enter this: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
On the right side, find the key LongPathsEnabled, double click on it, and change the value from 0 to 1
Restart VS2019, clean (if needed) and build your project again. The error should be fixed.
General workaround (VS2017/VS2019)
We can create a link of the original longer path to a shorter one. Then, VS will treat the shorter path as project root and the issue will be solved.
Create a shorter root path for project, e.g. we have created "D:\project" directory
Now open cmd (Command Prompt) and Create a symbolic link using this command: mklink /D "D:\project\myProject" "YOUR_ACTUAL_LONG_PATH_PROJECT_ROOT_DIRECTORY" [You may need to open cmd as administrator if above command fails to execute]
Now, open VS project from the "D:\project\myProject" directory and it should work.
No worry....This error comes because of long path name,Suppose your project folder name is "myproject".
You Just Change location of project folder...Put your Project "myproject" to D:\myproject or or F:\myproject drive.Then You Publish again..Its work...
Happy Coding...
It is issue with build defination workspace "Build Agent Folder location"
VS adds paths example:
$(SourceDir)E:\Somedirectory\ProjectName\
Just keep $(SourceDir) in filed
I had the same problem. My checkout path was shorter than the path used on my CI server. It built OK on the CI server, and all my colleagues machines. Our paths are the same length because our company has fixed length user names. I was the only machine that could not build the solution due to long paths.
If you go to these folders:
C:\Windows\Microsoft.NET\Framework
C:\Windows\Microsoft.NET\Framework64
C:\Users\[UserName]\AppData\Local\Temp
Find the version of .NET you are using with your solution, then delete the "Temporary ASP.NET Files" folders from which ever versions you think are effecting your build.
You can delete them all, your next build of a web project might take a little bit longer as there will be no pre-compiled assemblies...
This solution worked for me on a solution containing ASP.NET projects - it wont work on WPF projects that others have mentioned in their answers, unless their solution also contains ASP.NET projects.
Searching for the error string VS gives you brought me here, so I figured it might help someone else, if not the Op with a WPF build issue.
If these fail - you can try searching your solution root recursively for files/folders with paths that are greater the 260, by performing the following:
Open Powershell
cd <path to solution root>
cmd /c dir /s /b |? {$_.length -gt 260} > output.txt
This will pipe a list of files with paths > 260 to the output.txt file which will be newly created in the root of your solution.
This will help you find files within your solution that are too long.
For this, you have to run Power Shell on Windows as an administrator, and then type:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
This solved the issue
Error message :
"svn: Can't open file '/Users/username/Projects/myproject/trunk/project/.svn/text-base/filetoupdate.h.svn-base': No such file or directory"
Question:
I have an issue I've replaced a file in a project (in Xcode) with a new file (For reference and if this makes a difference, the new file has the same name as the one I deleted previously).
Now when I try to commit my changes in Xcode I get the error message detailed above and am unable to commit the changes (i.e. adding the new file).
In the file system view (in Xcode on the left hand side of the screen) the file has an R next to it (indicating Replaced in the repository).
Does anyone know how to fix it so I can commit the files?
Thanks
There is a bug or limitation in Subversion when using case-insensitive filesystems:
https://superuser.com/questions/303348/cant-checkout-in-subversion
This bug normally shows up when checking out a repository that contains two files whose names differ only in case. Of course, these cannot exist at the same time in the same directory on a case-insensitive filesystem. SVN could give a much more helpful error message, but it can't really solve the problem.
Your issue is a bit different because I assume the file filetoupdate.h (with the old case) no longer exists in your filesystem. So it's not a case conflict in the working directory. But I guess that SVN is trying to create the file in .svn/text-base with the new case, while the old one still exists, and that is failing (for the same reason).
You could try deleting the file from Subversion first, keeping the local copy (untested). The new copy must be removed from SVN control for the commit to succeed:
svn rm --keep-local --force FileToUpdate.h
And the old copy must be removed as well, to allow us to add the new copy later:
svn rm --keep-local filetoupdate.h
Commit this change:
svn commit
Now hopefully you can add the new file to version control:
svn add FileToUpdate.h
If that doesn't work, you might need to blow away the whole checkout and start again with a fresh one.
Are you on a Mac or Windows? Those have case-insensitive filesystems which causes the above problem when
a file currently exists with the same name but with different cases.
To fix , checkout out the tree on a Linux machine, then "svn rm" one of the files.
Maybe your local version has permission issues. Check if your user have the permissions to write for the .svn directories.
good luck
It looks like something got confused somewhere. To fix, I simply copied the offending files, saved them under a new name. Removed the originals from the project and the added the copied (renamed) version of the file to the project.
It seems to be that SVN doesn't like it if you add and remove a file with the same name. I tried cleaning the SVN through terminal, but it had no affect on this issue. But changing the name did work for me.