Firstly I read through many existing threads and followed the instructions there
Here
Here
Here
Here
Here
Here
Almost all the above threads asked me to delete the cache file. I went into the machine and deleted the cache file. I even edited the cache file (XML file named version config) but still it gets overwritten
But still even after that I am seeing the same issue.
The build agent has got dynamic $SourceDir as value
What else can I do to fix this? Please Help.
I tried doing tf workspaces but it simply keeps saying that "Unable to determine the source control server"
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets (838): Unable to create the workspace 'NVM1756PDV_105_7' due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer:%COMPUTERNAME%'.
Details: The path C:\Builds\7\Common_Security\cloud\src is already mapped in workspace NVM1756PDV_104_7.
Run the tf workspace /delete NVM1756PDV_104_7 command to correct this error.
Try using TFS Sidekicks to delete the workspace using the Workspace Sidekick.
Related
I delete my unity project which has a .git folder and ask me to create an encryption key I don't know why it asks me to do that, now when I try to add files in git it refuses to add any things and it prompts this error
The file will have its original line endings in your working directory
error: open("Temp/UnityLockfile"): Permission denied
error: unable to index file 'Temp/UnityLockfile'
fatal: adding files failed
Any suggestion
In general the Temp folder is one of the things you do NOT want to be under version control! It should be ignored as mentioned by the first comment! Use this .gitignore file in the root folder of your git project!
Also see Cleaning up and Migrating existing Unity project into new one or another PC where I explained it a bit more in detail and also how to copy your project with only the necessary files.
As said if there is no such file yet simply create it, otherwise adopt the content accordingly.
Also refer to How can I make Git "forget" about a file that was tracked, but is now in .gitignore?.
In your specific case here the error itself is caused because you currently have your project opened in Unity.
In that case there is the - as the name says - LOCK file which ensures you cannot open the same project twice in a second Unity instance.
This file is locked/owned by the Unity Editor process itself and therefore can't be overwritten/accessed by git at the same time.
Now if for some reason after adding the .gitignore file mentioned above this issue still persists you can close Unity, manually delete the Temp folder, make your git merge and reopen Unity.
Is there an easy way to find files that are not checked into my repository in my Visual Studio project?
In the past, there's been times when I get my code base from the repo only to realize that some files -- for some reason -- had not been checked into the repository.
I recently got a new laptop and downloaded the code for my app onto my new machine. I'm now getting an error when I run the app on the new laptop but on the old one it runs perfectly fine. My first thought was that there were configuration differences between two machines so I downloaded the code into a new folder on the old machine and started having the same error that I'm having on the new laptop. If I run the app from the original folder on the old machine, it runs fine.
This makes me think that I may have some differences in the code between what's on the repo and the original folder. As a result, if I get the code from the repo, I have the error. If I try to check in the code from the original folder on the old laptop, Visual Studio tells me that there's nothing to check in.
So, is there an easy way for me to see if there's any file that is not checked into the repo on my old laptop?
BTW, I'm running Visual Studio 2019 -- with the latest updates/patches -- and my repo is on Azure DevOps and uses TFVC.
Running tf vc status /format:detailed /recursive from a Visual Studio Developer Commandline in your workspace root should give you a good overview of files not checked in and files with pending changes.
C:\Users\JesseHouwing\source\Workspaces\xxx>tf vc status /format:detailed /recursive
-----------------------------------------------------------------------------------------------------------------------
Detected Changes:
-----------------------------------------------------------------------------------------------------------------------
$/xxx/test.txt
User : Jesse Houwing
Date : zaterdag 27 juli 2019 21:20:00
Lock : none
Change : add
Workspace : SHARKIE
Local item : [SHARKIE] C:\Users\JesseHouwing\Source\Workspaces\xxx\test.txt
0 change(s), 1 detected change(s)
It should auto-detect files unless you specify the /nodetectchanges flag.
Or, if your .tfignore file is well specified, you can run tf vc add * /recursive to automatically create a pending change for all files that are currently not under version control. If needed, edit your tfignore file before running the add command. Add /noignore to bypass the ignore file, but that may add bin and obj and packages folders as well, be careful.
tf.exe is hidden deep in the bowels of Visual Studio, easiest way to get access to it is to use the Developer Command Prompt:
My installation has put it here:
C:\Users\JesseHouwing\source\Workspaces\xxx>where tf
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe
After updating macOS to Mojave (10.14.4), my Mac was restarted and upon opening Jenkins (at localhost:8080) it appeared that I've lost all my jobs and the entire system configurations.
There was only 1 user (admin) defined in my installation and my usual password was deemed invalid, when I tried to log back in. So, I tried entering another password I normally used and it was accepted. I then found that all my jobs and configs have disappeared. It looked as if I've just started Jenkins for the first time.
Looking through here on StackOverFlow, there were suggestions to check the JENKINS_HOME variable to find out where the jobs are saved on the disk, but when I typed export $JENKINS_HOME I just get an empty response. So, it looks like I've never configured it during set up.
I then dig through the hard drive and found the folders matching the names of the jobs I created under ~/.jenkins/workspace. However, the contents of all the folders are empty. I was expecting to see the usual files, e.g. build.xml, config.xml, etc.
I then did a global search for build.xml and config.xml on Mac Finder it turned up nothing.
Any idea where my jobs went and what could have caused all the contents of the folders of the jobs to be empty?
You can find your Jenkins installation directory in "Manage Jenkins" -> "configure System" --> "Home directory". Find what was the Jenkins home before you restart MAC. It looks like your home directory is either deleted by you or you are pointing to new folder now. Set it to earlier folder.
If can help,
I'm having a similar problem.
The curious part is about the new directory after the service restart ".jenkins" directory inside :
'/var/root/'.
And now, the password that Jenkins request me is not from
'/Users/username/.jenkins/secrets/initialAdministratorPassword' but from the newst one with same path pattern.
Simon
This is really weird.
I am trying a clean Teamcity 9.1.1 install but the Data Directory is nowhere to be found.
if I access the Global Settings tab under Administration, it lists "C:\Windows\System32\config\systemprofile.BuildServer" - a folder that doesn't exist.
if I try to browse to that folder, it shows me a range of files; uploading a specific file there instead uploads it to C:\Windows\SysWOW64\config\systemprofile.BuildServer.
there is no teamcity-startup.properties file anywhere - I am unable to customize the location of the data directory.
when I restore a backup, the backup files are instead restored to C:\Users\[user name]\.BuildServer rather than in the correct data directory.
Does anyone has any suggestions on how to regain control of the situation? How can I tell TeamCity which data folder to use?
I resolved the situation by:
stopping TC services;
creating a teamcity-startup.properties in [install folder]\conf with the following content:
teamcity.data.path=D:\\[install folder]\\config
restarting TC services;
restoring my backup.
This restored the 9.1.1 install as well as stabilizing the location of the data directory. After this was done, the subsequent installation of 9.1.7 prompted me to uninstall 9.1.1 first (which it hadn’t done the first time around) and the upgrade succeeded.
I believe the system was already compromised at the beginning, unknown to me, due to the data folder being all over the place. Once that was resolved, everything else fell into place.
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.