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.
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.
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.
I've installed Collabnet Subversion Edge, and would like to make sure I have it backed up properly. I would like NOT to use the CloudBackup service offered.
I've went to the administration interface for collabnet (localhost:3343) and went to Repositories > Backup Schedule. There, one can choose between 3 different 'Type of Job':
Cloud Services Backup
Full Dump Backup
Hotcopy Backup
Neither lets you choose where to copy the backup. I've tried looking up how this works, but documentation seems to be lacking a lot.
What is the best way to backup such a repository? Shall I just keep a copy of the entire collabnet folder (c:\csvn)?
The Subversion Edge admin UI lets you specify the folder for backups. It defaults to a folder inside the normal data folder, but you can specify a different value. So, for example, if you have a D:\ drive that you want the backups to go on you can just specify that folder in the settings and the backups will go to that folder.
It does need to be a physically accessible hard drive though.
See the Backup Directory configuration item in this screenshot:
https://ctf.open.collab.net/sf/projects/svnedge/screenshots/screens/config/config.png
You can use Windows Server Backup to backup Subversion repositories. It allows you to shedule backups
to a network share, dedicated backup volume, writeable media. For example, wbadmin command-line tool allows you to safely backup your repositories. This simple command performs one-time copy backup of C:\foo\bar to X:\ volume:
wbadmin start backup –backupTarget:x: -include:c\foo\bar -vsscopy
(To install Windows Server Backup, run ocsetup WindowsServerBackup in elevated command-prompt).
You can setup backup in different ways:
wbadmin command-line tool,
PowerShell cmdlets, good for automation and customization of backup actions,
Windows Server Backup wizard (control panel, actually) MMC snap-in.
It's not required to stop server's service when you run the backup because FSFS repository backend is always in consistent state.
Here are general tips about recovering Subversion repository from a backup:
Recover repository backup to an empty directory to make sure that restored repository files won't mix with files of the broken one. After repository if recovered, you can delete broken repository and then replace it with the recovered one.
Stop-start cycle your Subversion server after recovering repository from a backup.
If your clients get errors after repository recover, run svnadmin recover against it. The command finishes instantly and makes repository accessible again.
If you have access to the repository directories then you should be able to use hotcopy directly and specify where the backups go.
It's enough to take a periodical backup of just csvn/data directory where all your repositories and configuration files are stored.
Visit this link for backup (and upgrade) options. The contents in the link is added below. Hope it helps.
Manual Upgrade/Reinstallation Steps
Subversion Edge includes an integrated mechanism for installing updates. This is the preferred way to do an upgrade as it handles whatever steps are needed to perform the upgrade and can be done remotely from your web browser. However, there are scenarios where you might want or need to do an upgrade manually, for example your Subversion Edge server might not be able to access the Internet to pull down the updates or maybe one or more critical installation files have become corrupted and you need to reinstall using the same version. Here are the steps for performing a manual upgrade or reinstallation:
Windows
If your existing Subversion Edge installation was installed using the installer from Subversion Edge 2.0.0 or later, then all you need to do to upgrade is download the latest installer and run it. This will uninstall the current version and install the new version (which is how the Windows Installer (.msi) process works for upgrades).
If you are not sure what version you installed with, you can always safely use this approach:
Stop the existing services and uninstall the current version from the
Windows Control Panel. This will leave behind your C:\csvn folder and
any files in it that have been modified since the original install.
Delete everything in the C:\csvn folder EXCEPT the data folder. So
you should be left with just the C:\csvn\data folder.
Install the new version. The installer will pick up the existing data folder and when the services start it will basically just be an upgrade to the new
version.
WARNING: Take note of this reported bug and backup the svn_access_file first:
artf7081 - Using Windows installer for updates can overwrite the svn_access_file
Linux/Solaris
To upgrade a Linux/Solaris installation, this is the safest way to do it:
Stop the servers $ bin/csvn stop $ bin/csvn-httpd stop
Rename the csvn folder $ mv csvn csvn-old
Untar the new release as a non-root user
Move the data folder back into the new release
$ mv csvn-old/data csvn
Important! Copy "dist" configuration files to data folder
$ cp -f csvn/dist/*.dist csvn/data/conf
Start the servers
$ bin/csvn start
$ bin/csvn-httpd start
When Xcode makes it's auto-snapshots, prior to a global find-and-replace for instance, the snapshot is created without error. When I select File -> Create Snapshot the machine chugs away for 10-15 minutes (this is posted without hyperbole), and then fails with an error message similar to:
**Unable to create a snapshot**
fatal: unable to stat 'Users/{me}/Library/Caches/Google/Chrome/Default/Cache/f_00476e': No such file or directory
Yes, that's the cache file for my browser. No, it's not explicitly included in my project. How can I tell Xcode to not do this? I am using the default Snapshot folder, which is
/Users/{me}/Documents/Development/KissQuest/Snapshots
PS -> I don't have the courage to test whether or not the Xcode--auto-generated snapshots are valid.
I'll answer my own question for posterity.
For some reason, there was a .git and .gitK lurking in /users/{me}; I killed those and then git init in the project folder and voila, re-initialized and running git.
git init was not enough; I had to purge the folder tree of bad .gits.
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.