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.
I recently installed Bonobo git server on my workstation. It will work as a git server for me and my colleagues. Using a script, the repositories will be stored on a separate server usinng a .bat file to copy the files regularly. The problem is I don't know where to find the repo files. I selected D:/git_repo as destination for bonobo repositories, but when i go there in explorer, there are only a few files and not the sources (the folders are alos only a few hundreads kbs big).
Do you have any ideea where the complete files are located?
If it was me, instead of using a scheduled script to copy the repository files to a separate server, I would on the destination/backup server have a scheduled task that performed a 'git pull' from your server.
Did you changed the Repository directory in the Bonobo UI settings ?
If you did, try to restart the IIS service.
If none helps, thenWhat exactly are you copying ? If your repositories are initialy exist, either by a script you execute or by the Bonobo UI, they can be created directly to your D:\Git_Repos as you specify
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
I have an eclipse synchronized project where I do the work on my Windows machine and then synchronize and compile it on the linux build server. However, the Windows workspace is connected to perforce and the linux one is not. The problem is that when Eclipse synchronizes the two, the permissions get messed up on the linux side so that I cannot execute certain shell scripts that usually execute during the build. The workaround that I have would be to somehow chmod all the *.sh files before executing a build, but I would much rather have perforce know about both places (that way I could also commit from either the linux side or the windows side). For performance reasons, I couldn't run eclipse on the remote build server so this was the only solution I found. Also, when I tried setting up a second workspace for the linux side, it gave me errors saying "could not clobber X". I think the main problem is that I'm dealing with some sort of permissions issue here.
I may have found the answer. According to the perforce documentation:
By default, you can only use a workspace on the machine that is specified by the Host: field. If you want to use the same client workspace on multiple machines with different platforms, delete the Host: entry and set the AltRoots: field in the client specification. You can specify a maximum of two alternate client workspace roots. The locations must be visible from all machines that will be using them, for example through NFS or Samba mounts.
Perforce compares the current working directory against the main Root: first, and then against the two AltRoots: if specified. The first root to match the current working directory is used. If no roots match, the main root is used.
Note
If you are using a Windows directory in any of your client roots, specify the Windows directory as your main client Root: and specify your other workspace root directories in the AltRoots: field.
In the following example, if user bruno's current working directory is located under /usr/bruno, Perforce uses the UNIX path as his client workspace root, rather than c:\bruno_ws. This approach allows bruno to use the same client workspace specification for both UNIX and Windows development.
Client: bruno_ws
Owner: bruno
Description:
Created by bruno.
Root: c:\bruno_ws
AltRoots:
/usr/bruno/
To find out which workspace root is in effect, issue the p4 info command and check the Client root: field.
If you edit text files in the same workspace from different platforms, ensure that the editors and settings you use preserve the line endings. For details about line-endings in cross-platform settings, refer to the Perforce System Administrator's Guide.
You could have two workspaces, one for each machine. When you've done the work on the Windows machine, you could shelve the changes, and then unshelve them on the Linux machine and do the build there.
I did the following to set up alternate roots in Perforce:
Created a workspace in Windows
Set the current client (workspace) with "p4 set P4CLIENT=workspace_name", I used Windows+Cygwin to do this
Removed the "Host" from this client (workspace) "p4 client -o | grep -v Host: | p4 client -i" I used Windows+Cygwin to do this
In Linux added the alternate root in P4V, don't use ~, use the absolute path, I didn't test environment variables
Switched to the workspace in P4V
Got the latest revision in P4V, and checked the "Force" option
References:
http://answers.perforce.com/articles/KB/3412
Override host to null in perforce client creation
https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html
sqenixs's answer here
What methods are available for backing up repositories in a Windows environment?
You could use something like (Linux):
svnadmin dump repositorypath | gzip > backupname.svn.gz
Since Windows does not support GZip it is just:
svnadmin dump repositorypath > backupname.svn
We use svnadmin hotcopy, e.g.:
svnadmin hotcopy C:\svn\repo D:\backups\svn\repo
As per the book:
You can run this command at any time and make a safe copy of the repository, regardless of whether other processes are using the repository.
You can of course ZIP (preferably 7-Zip) the backup copy. IMHO It's the most straightforward of the backup options: in case of disaster there's little to do other than unzip it back into position.
There's a hotbackup.py script available on the Subversion web site that's quite handy for automating backups.
http://svn.apache.org/repos/asf/subversion/trunk/tools/backup/hot-backup.py.in
Here is a Perl script that will:
Backup the repo
Copy it to another server via SCP
Retrieve the backup
Create a test repository from the backup
Do a test checkout
Email you with any errors (via cron)
The script:
my $svn_repo = "/var/svn";
my $bkup_dir = "/home/backup_user/backups";
my $bkup_file = "my_backup-";
my $tmp_dir = "/home/backup_user/tmp";
my $bkup_svr = "my.backup.com";
my $bkup_svr_login = "backup";
$bkup_file = $bkup_file . `date +%Y%m%d-%H%M`;
chomp $bkup_file;
my $youngest = `svnlook youngest $svn_repo`;
chomp $youngest;
my $dump_command = "svnadmin -q dump $svn_repo > $bkup_dir/$bkup_file ";
print "\nDumping Subversion repo $svn_repo to $bkup_file...\n";
print `$dump_command`;
print "Backing up through revision $youngest... \n";
print "\nCompressing dump file...\n";
print `gzip -9 $bkup_dir/$bkup_file\n`;
chomp $bkup_file;
my $zipped_file = $bkup_dir . "/" . $bkup_file . ".gz";
print "\nCreated $zipped_file\n";
print `scp $zipped_file $bkup_svr_login\#$bkup_svr:/home/backup/`;
print "\n$bkup_file.gz transfered to $bkup_svr\n";
#Test Backup
print "\n---------------------------------------\n";
print "Testing Backup";
print "\n---------------------------------------\n";
print "Downloading $bkup_file.gz from $bkup_svr\n";
print `scp $bkup_svr_login\#$bkup_svr:/home/backup/$bkup_file.gz $tmp_dir/`;
print "Unzipping $bkup_file.gz\n";
print `gunzip $tmp_dir/$bkup_file.gz`;
print "Creating test repository\n";
print `svnadmin create $tmp_dir/test_repo`;
print "Loading repository\n";
print `svnadmin -q load $tmp_dir/test_repo < $tmp_dir/$bkup_file`;
print "Checking out repository\n";
print `svn -q co file://$tmp_dir/test_repo $tmp_dir/test_checkout`;
print "Cleaning up\n";
print `rm -f $tmp_dir/$bkup_file`;
print `rm -rf $tmp_dir/test_checkout`;
print `rm -rf $tmp_dir/test_repo`;
Script source and more details about the rational for this type of backup.
I use svnsync, which sets up a remote server as a mirror/slave. We had a server go down two weeks ago, and I was able to switch the slave into primary position quite easily (only had to reset the UUID on the slave repository to the original).
Another benefit is that the sync can be run by a middle-man, rather than as a task on either server. I've had a client to two VPNs sync a repository between them.
svnadmin hotcopy
svnadmin hotcopy REPOS_PATH NEW_REPOS_PATH
This subcommand makes a full “hot” backup of your repository, including all hooks, configuration files, and, of course, database files.
svnbackup over at Google Code, a .NET console application.
You can create a repository backup (dump) with svnadmin dump.
You can then import it in using svnadmin load.
Detailed reference in the SVNBook:
"Repository data migration using svnadmin"
Basically it's safe to copy the repository folder if the svn server is stopped. (source: https://groups.google.com/forum/?fromgroups#!topic/visualsvn/i_55khUBrys%5B1-25%5D )
So if you're allowed to stop the server, do it and just copy the repository, either with some script or a backup tool. Cobian Backup fits here nicely as it can stop and start services automatically, and it can do incremental backups so you're only backing up parts of repository that have changed recently (useful if the repository is large and you're backing up to remote location).
Example:
Install Cobian Backup
Add a backup task:
Set source to repository folder (e.g. C:\Repositories\),
Add pre-backup event "STOP_SERVICE" VisualSVN,
Add post-backup event, "START_SERVICE" VisualSVN,
Set other options as needed. We've set up incremental backups including removal of old ones, backup schedule, destination, compression incl. archive splitting etc.
Profit!
there are 2 main methods to backup a svn server, first is hotcopy that will create a copy of your repository files, the main problem with this approach is that it saves data about the underlying file system, so you may have some difficulties trying to repostore this kind of backup in another svn server kind or another machine.
there is another type of backup called dump, this backup wont save any information of the underlying file system and its potable to any kind of SVN server based in tigiris.org subversion.
about the backup tool you can use the svnadmin tool(it is able to do hotcopy and dump) from the command prompt, this console resides in the same directory where your svn server lives or you can google for svn backup tools.
my recommendation is that you do both kinds of backups and get them out of the office to your email acount, amazon s3 service, ftp, or azure services, that way you will have a securityy backup without having to host the svn server somewhere out of your office.
Here a GUI Windows tool for make a dump of local and remote subversion repositories:
https://falsinsoft-software.blogspot.com/p/svn-backup-tool.html
The tool description says:
This simply tool allow to make a dump backup of a local and remote subversion repository. The software work in the same way of the "svnadmin" but is not a GUI frontend over it. Instead use directly the subversion libraries for allow to create dump in standalone mode without any other additional tool.
Hope this help...
I like to just copy the entire repo directory to my backup location. That way, if something happens, you can just copy the directory back and be ready to go immediately.
Just make sure to preserve permissions, if needed. Usually, this is only a concern on Linux machines.
For hosted repositories you can since svn version 1.7 use svnrdump, which is analogous to svnadmin dump for local repositories. This article provides a nice walk-through, which essentially boils down to:
svnrdump dump /URL/to/remote/repository > myRepository.dump
After you have downloaded the dump file you can import it locally
svnadmin load /path/to/local/repository < myRepository.dump
or upload it to the host of your choice.
If you are using the FSFS repository format (the default), then you can copy the repository itself to make a backup. With the older BerkleyDB system, the repository is not platform independent and you would generally want to use svnadmin dump.
The svnbook documentation topic for backup recommends the svnadmin hotcopy command, as it will take care of issues like files in use and such.
#echo off
set hour=%time:~0,2%
if "%hour:~0,1%"==" " set hour=0%time:~1,1%
set folder=%date:~6,4%%date:~3,2%%date:~0,2%%hour%%time:~3,2%
echo Performing Backup
md "\\HOME\Development\Backups\SubVersion\%folder%"
svnadmin dump "C:\Users\Yakyb\Desktop\MainRepositary\Jake" | "C:\Program Files\7-Zip\7z.exe" a "\\HOME\Development\Backups\SubVersion\%folder%\Jake.7z" -sibackupname.svn
This is the Batch File i have running that performs my Backups
For the daily and full backup solution just use the SVN backup scripts here.
I have compiled the steps I followed for the purpose of taking a backup of the remote SVN
repository of my project.
install svk (http://svk.bestpractical.com/view/SVKWin32)
install svn (http://sourceforge.net/projects/win32svn/files/1.6.16/Setup-Subversion-1.6.16.msi/download)
svk mirror //local <remote repository URL>
svk sync //local
This takes time and says that it is fetching the logs from repository. It creates a set of files inside C:\Documents and Settings\nverma\.svk\local.
To update this local repository with the latest set of changes from the remote one, just run the previous command from time to time.
Now you can play with your local repository (/home/user/.svk/local in this example) as if it were a normal SVN repository!
The only problem with this approach is that the local repository is created with a revision increments by the actual revision in the remote repository. As someone wrote:
The svk miror command generates a commit in the just created repository. So all the commits created by the subsequent sync will have revision numbers incremented by one as compared to the remote public repository.
But, this was OK for me as I only wanted some backup of the remote repository time to time, nothing else.
Verification:
To verify, use the SVN client with the local repository like this:
svn checkout "file:///C:/Documents and Settings\nverma/.svk/local/" <local-dir-path-to-checkout-onto>
This command then goes to checkout the latest revision from the local repository. At the end it says Checked out revision N. This N was one more than the actual revision found in the remote repository (due to the problem mentioned above).
To verify that svk also brought all the history, the SVN checkout was run with various older revisions using -r with 2, 10, 50 etc. Then the files in <local-dir-path-to-checkout-onto> were confirmed to be from that revision.
At the end, zip the directory C:/Documents and Settings\nverma/.svk/local/ and store the zip somewhere. Keep doing this regularly.
as others have said, hot-backup.py from the Subversion team has some nice features over just plain svnadmin hotcopy
I run a scheduled task on a python script that spiders for all my repositories on the machine, and uses hotbackup to keep several days worth of hotcopies (paranoid of corruption) and an svnadmin svndump on a remote machine. Restoration is really easy from that - so far.
1.1 Create Dump from SVN (Subversion) repository
svnadmin dump /path/to/reponame > /path/to/reponame.dump
Real example
svnadmin dump /var/www/svn/testrepo > /backups/testrepo.dump
1.2 Gzip Created Dump
gzip -9 /path/to/reponame.dump
Real example
gzip -9 /backups/testrepo.dump
1.3 SVN Dump and Gzip Dump with One-liner
svnadmin dump /path/to/reponame | gzip -9 > /path/to/reponame.dump.gz
Real example
svnadmin dump /var/www/svn/testrepo |Â gzip -9 > /backups/testrepo.dump.gz
How to Backup (dump) and Restore (load) SVN (Subversion) repository on Linux.
Ref: svn subversion backup andrestore