My Backup Script
For your information, this is my backup script. It produces a zip file that can be tranported to another computer. The zip file unpacks into a repository collection, giving, for each repository, a hotcopy of the repository and a dump of the repository. The hotcopy can be reloaded on a computer with the same characteristics as the original server; the dumps can be loaded onto a different computer. Comments are welcome. #! /bin/bash # requires root access if [ ! `whoami` == root ] then sudo $0 exit fi # controlling parameters SRCE=/data/svn ls -ld $SRCE DEST=/data/svnbackup APACHE_USER=www-data APACHE_GROUP=www-data # Construct a new empty SVNParent repository collection rm -rf $DEST mkdir $DEST chown $APACHE_USER $DEST chgrp $APACHE_GROUP $DEST chmod 0700 $DEST ls -ld $DEST # Get all the names of all the repositories # (Also gets names of any other entry in the SVNParent directory) cd $SRCE ls -d1 * /tmp/SVNBackup.tmp # Process each repository for REPO in `cat /tmp/SVNBackup.tmp` do # some things are not repositories; ignore them if [ -d $SRCE/$REPO ] then # back up this repository echo Backing up $REPO # use hotcopy to get an exact copy # that can be reloaded onto the same system svnadmin hotcopy $SRCE/$REPO $DEST/$REPO # use dump to get an inexact copy # that can be reloaded anywhere svnadmin dump $SRCE/$REPO $DEST/$REPO.dump fi done # Show the contents echo Contents of the backup: ls -ld $DEST/* # zip up the result cd $DEST zip -r -q -y $DEST.zip . # Talk to the user echo Backup is in file $DEST.zip: ls -ld $DEST.zip # The file $DEST.zip can now be transported to another computer.
AW: copying subdirectories in subversion 1.7
Hi, Daniel, Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Markus Schaber wrote on Mon, Jul 25, 2011 at 15:57:00 +0200: Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] So I'm not only detaching subdirectories, but also re-implanting them afterwards. Sounds like what you really need is this as-of-yet not implemented feature: http://subversion.tigris.org/issues/show_bug.cgi?id=3625 Yes, that one would definitely help. :-) Maybe extending svn diff and svn patch to preserve copy/rename/history information would already be half of that implementation? A shelve subdir under .svn/ could then be used to store the diff files. That's one solution. However, wc.db already has the ability to represent multiple related trees (via op_depth), so another way would be to extend that into storing not only the post-'svn patch' trees too, and then merging them in the usual way. (which may require repository communication, or storing the pre- patch tree locally too...) I think your suggestion sounds a little bit more complex to start with. Shelving of patches in .svn/shelve/ can be implemented independently of the diff/patch extension (with the disadvantage of losing history for now), and can even be implemented as an external tool / script. Extending the diff and patch commands to preserve history (maybe just by a pointer to url@rev) has benefits for other uses (like sending patches to someone else). Perhaps you'd be interested in contributing to the implementation of this feature? Yes, I am, but I've only very limited time to work on it while being at home. Best regards, Markus Schaber
Re: configure subversion for no history
Guten Tag Kent Rollins, am Montag, 25. Juli 2011 um 19:29 schrieben Sie: Is there a way to configure Subversion to *not* store a history on certain files? No. I have a few people checking in some large binaries and we really don't need to store history on them. We only need the last committed version of the file. The repository is growing unnecessarily large. Which version of Subversion are you using on the server side and what does those large files look like or of what type are they? Subversion compresses files, creates diffs and starting with version 1.6(?) is able to deduplicate commits by default. I have some repositories where I commit MSI-installers and all stuff of binary files for one of our applications and Subversion 1.6 saved GB of space. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: My Backup Script
On 7/25/2011 11:33 PM, Andy Canfield wrote:
For your information, this is my backup script. It produces a zip file
that can be tranported to another computer. The zip file unpacks into
a repository collection, giving, for each repository, a hotcopy of the
repository and a dump of the repository. The hotcopy can be reloaded
on a computer with the same characteristics as the original server;
the dumps can be loaded onto a different computer. Comments are welcome.
The dump should use the hot copy as its source. Otherwise it may differ
from the hot copy. See my note inline.
#! /bin/bash
# requires root access
if [ ! `whoami` == root ]
then
sudo $0
exit
fi
# controlling parameters
SRCE=/data/svn
ls -ld $SRCE
DEST=/data/svnbackup
APACHE_USER=www-data
APACHE_GROUP=www-data
# Construct a new empty SVNParent repository collection
rm -rf $DEST
mkdir $DEST
chown $APACHE_USER $DEST
chgrp $APACHE_GROUP $DEST
chmod 0700 $DEST
ls -ld $DEST
# Get all the names of all the repositories
# (Also gets names of any other entry in the SVNParent directory)
cd $SRCE
ls -d1 * /tmp/SVNBackup.tmp
# Process each repository
for REPO in `cat /tmp/SVNBackup.tmp`
do
# some things are not repositories; ignore them
if [ -d $SRCE/$REPO ]
then
# back up this repository
echo Backing up $REPO
# use hotcopy to get an exact copy
# that can be reloaded onto the same system
svnadmin hotcopy $SRCE/$REPO $DEST/$REPO
# use dump to get an inexact copy
# that can be reloaded anywhere
svnadmin dump $SRCE/$REPO $DEST/$REPO.dump
svnadmin dump $DEST/$REPO $DEST/${REPO}.dump
I generally use curly braces when punctuation is present to make sure
variable substitution occurs the way I want it.
fi
done
# Show the contents
echo Contents of the backup:
ls -ld $DEST/*
# zip up the result
cd $DEST
zip -r -q -y $DEST.zip .
# Talk to the user
echo Backup is in file $DEST.zip:
ls -ld $DEST.zip
# The file $DEST.zip can now be transported to another computer.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Re: How to clean the working dir from .svn folders ?
Guten Tag Damien Mistic, am Dienstag, 26. Juli 2011 um 00:00 schrieben Sie: Warning: unlink(svn/.svn/all-wcprops) [function.unlink]: Permission denied in C:\wamp\www\lang_editor\include\functions.inc.php on line 325 If you don't have permission executing unlink on those files, doing it within exec won't change a thing, right? The permissions stay the same, however they look like for your webserver. And the 'export' function is not what I want because my aim is to delete the folder, not really get a clean copy. But what is the difference between having a functional working copy, destroy it by deleting the .svn folders and a clean export, which is designed to make exactly what you want? Maybe you should describe your scenario a bit more. If there is no way I think we must add a new function to SVN, such as 'svn unlink' or 'svn dissociate' And what will this change if your error is permissions on the .svn-folders and files in there? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Source code lines transposed on checkout
On Monday 25 July 2011, Jeff Abbott wrote: I have on two occasions had two lines of code transposed on an SVN Tortoise checkout. I have never ever heard of any such thing, and I'm very surprised by it. Just to make sure, did you try a different editor? I could imagine crappy tools getting confused by inconsistent line endings or such things. In both cases the code was VB6. In each case an Exit command was transposed with an End If line. The code below provides an example. ' Case 1: End if Swapped with Exit For For ... If ... Then ... Exit For End If Next ' Case 2: End if Swapped with Exit Property If ... Then ... End If Exit Property On checkout to one computer the code was transposed as: ' Case 1: End if Swapped with Exit For For ... If ... Then ... End If Exit For Next ' Case 2: End if Swapped with Exit Property If ... Then ... Exit Property End If Strange. Is that effect repeatable? Additional detail: In each case I checked the same baseline out on a second computer and the lines were not swapped. I reversed the lines to correct for the error, and did a DIFF, which showed the line order correct. The diff showed the changes you made or the diff showed that the order was already correct? What does the diff show if you don't change anything, i.e. is the working copy already modified on checkout? What access method was used on checkout (file, http, https, svn, svn+ssh)? Could it be that some network proxy/filter/censorship/firewall application modifies the network traffic? I checked in and did a DIFF between the current code and the original revision, no differences were found. How exactly? SVN doesn't allow you to check in without changes. What does 'svn log' on the repository tell you about the created revision? We have not been able to repeat this problem. Wait: You have only had this issue a single time? Can you rule out that some user or machine accidentally modified the checked out files? But since the issue involves End If with Exit commands, different baselines, different users, and different SVN repositories, I'm at a loss on where to look next. BTW: What is a baseline? SVN doesn't use this term, so what exactly do you mean with it? Also, just to make sure since you have multiple repositories, you didn't fall for the trap that you created one with svnadmin and the others by copying? That would give all repositories the same UUID, which messes with SVN's internals. BTW2: You're sending HTML mail, please try to turn that off for mailinglists. Good luck! Uli ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **
AW: How to clean the working dir from .svn folders ?
Hi, Thorsten, Von: Thorsten Schöning [mailto:tschoen...@am-soft.de] Warning: unlink(svn/.svn/all-wcprops) [function.unlink]: Permission denied in C:\wamp\www\lang_editor\include\functions.inc.php on line 325 If you don't have permission executing unlink on those files, doing it within exec won't change a thing, right? The permissions stay the same, however they look like for your webserver. Maybe it is one of those files which are marked read-only by subversion? Unlink will fail with permission denied, but the user has the permission to re-mark the file read-write. rm -rf does that on unixoid systems. I don't know whether php has a built-in function, however. And the 'export' function is not what I want because my aim is to delete the folder, not really get a clean copy. But what is the difference between having a functional working copy, destroy it by deleting the .svn folders and a clean export, which is designed to make exactly what you want? There are at least 2 differences: - Local modifications won't be preserved. - Repository access is necessary. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Subtle mistake in the German help text for export
Hi! The output of svn help export contains these sentences: Ohne Angabe von REV werden alle lokalen Änderungen beibehalten. Objekte, die sich nicht unter Versionskontrolle befinden, werden in diesem Fall auch nicht kopiert. Compare this to the English version: If REV is not specified, all local changes will be preserved. Files not under version control will not be copied. The German version mistranslates the second sentence to Files not under version control will not be copied _in_ _this_ _case_., where said case can only refer to the previous sentence. This basically implies that unversioned files and folders are copied unless a specific revision is specified. Cheers! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
1.7 compatibility issue
Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn _binaries.windows ). With the alpha and beta clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' svn: E175009: XML parsing failed: (400 Bad Request) The Visual SVN event log shows the message Hostname :8443 provided via SNI and hostname provided via HTTP are different. There seems to be a missing port number which reminded me of a discussion in thread 1.7.0-alpha1 feedback (http://svn.haxx.se/users/archive-2011-06/0263.shtml). Maybe this is related. Versions svn-1.7.0-dev-win32-r1136035.zip and earlier work, though. Regards, Thomas This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
Re: SVN 1.7 SVNParentPath broken
On Tue, 2011-07-26 at 10:04 +0200, Mario Brandt wrote: I installed SVN/1.7.0-beta2 using it over apache 2.3.12, also tried the alphas before. With none of it I'm able to use SVNParentPath. I'm getting m:human-readable errcode=2 Could not open the requested SVN filesystem /m:human-readable This is because the repository format changed slightly between the alpha releases and the beta2 release. You will need to re-create the repository. I had the exact same problem, dump and load into a new repository worked for me. Tony Butt the same error if that wouldn't be a repo instead of showing the list of repos. my config Location / DAV svn SVNParentPath /opt/repos SVNListParentPath on SVNPathAuthz on #SVNIndexXSLT /svnindex.xsl AuthType Basic AuthName Subversion Repository AuthUserFile /opt/repos/htpasswd Require valid-user /Location Cheers Mario -- Tony Butt t...@cea.com.au CEA Technologies
Re: copying subdirectories in subversion 1.7
Markus Schaber wrote on Tue, Jul 26, 2011 at 09:11:57 +0200: Von: Daniel Shahaf Perhaps you'd be interested in contributing to the implementation of this feature? Yes, I am, but I've only very limited time to work on it while being at home. I see. Hope you find the time for it :)
Re: SVN 1.7 SVNParentPath broken
Tony Butt wrote on Tue, Jul 26, 2011 at 18:42:46 +1000: On Tue, 2011-07-26 at 10:04 +0200, Mario Brandt wrote: I installed SVN/1.7.0-beta2 using it over apache 2.3.12, also tried the alphas before. With none of it I'm able to use SVNParentPath. I'm getting m:human-readable errcode=2 Could not open the requested SVN filesystem /m:human-readable This is because the repository format changed slightly between the alpha releases and the beta2 release. You will need to re-create the repository. I had the exact same problem, dump and load into a new repository worked for me. First of all, this only applies if Mario ran 'svnadmin upgrade' using a 1.7-dev through 1.7.0-alpha3 client. Second of all, don't you get the error documented in http://subversion.apache.org/docs/release-notes/1.7#revprop-packing in that case?
Re: Subtle mistake in the German help text for export
On Jul 26, 2011, at 03:39, Ulrich Eckhardt wrote: The output of svn help export contains these sentences: Ohne Angabe von REV werden alle lokalen Änderungen beibehalten. Objekte, die sich nicht unter Versionskontrolle befinden, werden in diesem Fall auch nicht kopiert. Compare this to the English version: If REV is not specified, all local changes will be preserved. Files not under version control will not be copied. The German version mistranslates the second sentence to Files not under version control will not be copied _in_ _this_ _case_., where said case can only refer to the previous sentence. This basically implies that unversioned files and folders are copied unless a specific revision is specified. I agree this translation is misleading, and would suggest removing the words in diesem Fall auch from it.
Re: SVN 1.7 SVNParentPath broken
This is because the repository format changed slightly between the alpha releases and the beta2 release. You will need to re-create the repository. I had the exact same problem, dump and load into a new repository worked for me. The issues are not the repos. I can access my 1.6.17 and older repos without any issues. The file system layout is /opt/repos --- ParentPath /opt/repos/repo1 /opt/repos/repo2 /opt/repos/repo3 /opt/repos/repoN As it was in SVN 1.6 SVNParentPath should show a list of the repos 1,2,3 to N [1] Second of all, don't you get the error documented in http://subversion.apache.org/docs/release-notes/1.7#revprop-packing in that case? Nope I don't get that error. This is might related to the mod_dav_svn. I'm not sure. But at leat I can say that over apache (I don't use svnserve) I never had an issue with the 1.6.x repos with the mod_dav_svn 1.7.x apache module. Cheers Mario [1] http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.httpd.basic
Re: My Backup Script
On Tue, Jul 26, 2011 at 01:33:09PM +0700, Andy Canfield wrote:
For your information, this is my backup script. It produces a zip
file that can be tranported to another computer. The zip file
unpacks into a repository collection, giving, for each repository, a
hotcopy of the repository and a dump of the repository. The hotcopy
can be reloaded on a computer with the same characteristics as the
original server; the dumps can be loaded onto a different computer.
Comments are welcome.
Please also make a backup of every individual revision from the
post-commit hook, like this:
[[[
#!/bin/sh
REPOS=$1
REV=$2
svnadmin dump ${REPOS} -q --incremental --deltas -r ${REV}
/backup/${REV}.dmp
]]]
And make /backup a separate filesystem, preferably on a different host
or some disk storage that runs independently from the host.
You will thank me one day when your server's disks die at the wrong moment
e.g. because of power failure or overheating.
In such cases it is possible that not all data has been flushed to disk yet.
The only good data is in the OS buffer cache which the above svnadmin dump
command will get to see. However, even revisions committed several
*minutes* before such a crash can appear corrupted on disk when you reboot.
I've seen this happening (on Windows, with NTFS -- lots of damage;
but other operating systems aren't immune to this either).
We could tell that the buffer cache data was good because there were
multiple corrupted revision files (one repository had more than 20
broken revisions), each with random junk in some parts, and all broken
parts were 512 byte blocks, i.e. disk sectors. But in the parts that
were not broken they referred to each other in ways that made perfect
sense. So before the crash they were all OK. There were no backups so
we had to manually repair the revisions (this requires intricate
knowledge about the revision file format and takes time...)
When this happens you have an unusable repository. Anything referring
to the broken revisions will fail (commit, diff, update, ...).
Assuming the incremental dumps weren't destroyed in the catastrophe
you can load the incremental dumps on top of your last full backup and
get to a good state that is very close to the point in time when the
crash happened.
Without the incremental dumps you'll have the last full backup.
But anything committed since could be lost forever.
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 12:34, Becker, Thomas thomas.bec...@torex.com wrote: Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows ). With the “alpha” and “beta” clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' The URL for VisualSVN Server repositories should be like https:/xxx:8443/svn/. Please make sure that you are using correct URL to repository. -- Ivan Zhakov
Re: Subtle mistake in the German help text for export
On Tue, Jul 26, 2011 at 10:39:03AM +0200, Ulrich Eckhardt wrote: Hi! The output of svn help export contains these sentences: Ohne Angabe von REV werden alle lokalen Änderungen beibehalten. Objekte, die sich nicht unter Versionskontrolle befinden, werden in diesem Fall auch nicht kopiert. Compare this to the English version: If REV is not specified, all local changes will be preserved. Files not under version control will not be copied. The German version mistranslates the second sentence to Files not under version control will not be copied _in_ _this_ _case_., where said case can only refer to the previous sentence. This basically implies that unversioned files and folders are copied unless a specific revision is specified. Cheers! Thanks, fixed in trunk (r1151036), 1.7.x, and 1.6.x.
AW: 1.7 compatibility issue
Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas -Ursprüngliche Nachricht- Von: Ivan Zhakov [mailto:i...@visualsvn.com] Gesendet: Dienstag, 26. Juli 2011 11:26 An: Becker, Thomas Cc: users@subversion.apache.org Betreff: Re: 1.7 compatibility issue On Tue, Jul 26, 2011 at 12:34, Becker, Thomas thomas.bec...@torex.com wrote: Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows ). With the alpha and beta clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' The URL for VisualSVN Server repositories should be like https:/xxx:8443/svn/. Please make sure that you are using correct URL to repository. -- Ivan Zhakov This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschäftsführer: Stephen Callaghan, Martin Timmann. .
Re: How to clean the working dir from .svn folders ?
Hello, as svn is the owner of .svn directories I suppose it can delete them. More over according to my experience process launched into exec() have more rights that other php functions. For help here is my possible workflow : checkout some commits delete the working directory I'm in local on Windows for the moment, I'm going to install a local FTP server to check the rights of the files. But they are created by svn, in my mind it could delete them. Damien. -Message d'origine- From: Thorsten Schöning Sent: Tuesday, July 26, 2011 9:27 AM To: users@subversion.apache.org Subject: Re: How to clean the working dir from .svn folders ? Guten Tag Damien Mistic, am Dienstag, 26. Juli 2011 um 00:00 schrieben Sie: Warning: unlink(svn/.svn/all-wcprops) [function.unlink]: Permission denied in C:\wamp\www\lang_editor\include\functions.inc.php on line 325 If you don't have permission executing unlink on those files, doing it within exec won't change a thing, right? The permissions stay the same, however they look like for your webserver. And the 'export' function is not what I want because my aim is to delete the folder, not really get a clean copy. But what is the difference between having a functional working copy, destroy it by deleting the .svn folders and a clean export, which is designed to make exactly what you want? Maybe you should describe your scenario a bit more. If there is no way I think we must add a new function to SVN, such as 'svn unlink' or 'svn dissociate' And what will this change if your error is permissions on the .svn-folders and files in there? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
strange merge conflict wrt. keywords
Hi, We encountered a strange merge conflict: A branch was created from trunk, nothing was ever committed to this branch and this branch was never the source of a merge. After some time, when merging from trunk to the freshly checked-out branch we got a text conflict for a particular file. It turned out that the trunk version of this file had substituted keywords in the repository when the branch was created. With the next commit on trunk this changed back to the un-expanded forms. The change of the revision where the substituted keywords appeared in the repository was a move of three files in order to change an upper case letter to lower case in the file names. However, the substituted keywords appeared only in one of the files. The svn:keywords property was Id Date Revision Author URL for all three files in all revisions. My assumption is that when doing the merge from trunk to branch the keyword line is subject to an incoming change (because they changed back to the generic form on trunk) as well as to local substitution which leads to the observed conflict. My questions now are: - Is this the expected behaviour or should incoming changes on keywords be ignored? - How could the substituted keyword get into the repository? For the revision where the substituted keywords appear in the repository we used Windows clients and server (Visual SVN) in whatever version was recent in January 2011. The merge conflict can be observed with Linux and Windows clients in various 1.6 versions. Regards, Thomas This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
Re: My Backup Script
On 07/26/2011 04:20 PM, Stefan Sperling wrote:
On Tue, Jul 26, 2011 at 01:33:09PM +0700, Andy Canfield wrote:
For your information, this is my backup script. It produces a zip
file that can be tranported to another computer. The zip file
unpacks into a repository collection, giving, for each repository, a
hotcopy of the repository and a dump of the repository. The hotcopy
can be reloaded on a computer with the same characteristics as the
original server; the dumps can be loaded onto a different computer.
Comments are welcome.
Please also make a backup of every individual revision from the
post-commit hook, like this:
[[[
#!/bin/sh
REPOS=$1
REV=$2
svnadmin dump ${REPOS} -q --incremental --deltas -r ${REV}
/backup/${REV}.dmp
]]]
And make /backup a separate filesystem, preferably on a different host
or some disk storage that runs independently from the host.
In Linux a separate filesystem is often another partition on the hard
disk, and thus not to be trusted too much. For safety an external hard
disk, flushed, should be good enough. No need for an entire other host. Yes?
You will thank me one day when your server's disks die at the wrong moment
e.g. because of power failure or overheating.
In such cases it is possible that not all data has been flushed to disk yet.
The only good data is in the OS buffer cache which the above svnadmin dump
command will get to see. However, even revisions committed several
*minutes* before such a crash can appear corrupted on disk when you reboot.
Thank you very much.
Linux ext3 filesystems used to be pretty much immune to unflushed
buffers; anything older than 5 seconds would be written to disk. But
now, with ext4, there's no guarantee, and I've seen the thing have
unflushed buffers after one minute. And I'm not supposed to be able to
see that!
Of course, even Linux isn't immune to a burned-out hard disk controller.
As for overheading, I can't help but joke that perhaps the overheading
was caused by all the backups you were doing? Ha ha. Of course not!
I've seen this happening (on Windows, with NTFS -- lots of damage;
but other operating systems aren't immune to this either).
We could tell that the buffer cache data was good because there were
multiple corrupted revision files (one repository had more than 20
broken revisions), each with random junk in some parts, and all broken
parts were 512 byte blocks, i.e. disk sectors. But in the parts that
were not broken they referred to each other in ways that made perfect
sense. So before the crash they were all OK. There were no backups so
we had to manually repair the revisions (this requires intricate
knowledge about the revision file format and takes time...)
When this happens you have an unusable repository. Anything referring
to the broken revisions will fail (commit, diff, update, ...).
Assuming the incremental dumps weren't destroyed in the catastrophe
you can load the incremental dumps on top of your last full backup and
get to a good state that is very close to the point in time when the
crash happened.
Without the incremental dumps you'll have the last full backup.
But anything committed since could be lost forever.
Anything commited since the last full backup would be lost only if no
longer exists in the developer's working copy. The size of the mess
depends on how many commits you lost. Ten per developer per day, and 20
developer, is a massive headache. Two per developer per week, and three
developers, is not a catastrophe.
As I understand Subversion,
[a] The server has no idea who has a working copy.
[b] The checkout builds a working copy on the workstation from the
server's repository.
[c] What is on the developers hard disk is a working copy.
[d] What is on the developer's hard disk continues to be a working copy,
even after a commit.
[e] If the developer tries to make revisions to his working copy six
months after his last commit, then tries to commit, he's going to have a
major mess on his hands trying to reconcile things. The working copy is
still a valid working copy.
[f] Unlike a lock, which he grabs and then releases, he never gives up
his working copy; it is valid perpetually.
[g] The usual way a working copy goes away is with the rm -rf command.
Thanks for the great information!
RE: Custom diff3 command
Apologies, responded to wrong email L From: Adam Downer Sent: 26 July 2011 14:03 To: Adam Downer; Arpe, Kevin C; users@subversion.apache.org Subject: RE: Custom diff3 command Nope, besides, it will be a suitable send off for Jira to cause you a final bit of pain in using it J From: Adam Downer [mailto:adam.dow...@ri3k.com] Sent: 20 June 2011 16:39 To: Arpe, Kevin C; users@subversion.apache.org Subject: RE: Custom diff3 command You will need to write a wrapper script to perform this. Start here http://svnbook.red-bean.com/en/1.5/svn.advanced.externaldifftools.html and configure your subversion to kick off your custom wrapper. Manipulate the passed in args as you want them and output them to your diff prog. Hope this sets you on the right track. Adam D From: Arpe, Kevin C [mailto:kevin.c.a...@jpmorgan.com] Sent: 20 June 2011 04:31 To: users@subversion.apache.org Subject: Custom diff3 command Hi, I am a Subversion command-line tools user on Windows XP. Version string = svn, version 1.6.12 (r955767) / compiled Jun 21 2010, 16:00:59 I wrote my own diff3 command batch file. We use it on my team to redirect merges thru KDiff3. I have noticed the argument list is not very descriptive. I will follow GNU diff3 terminology: MYFILE, OLDFILE, YOURFILE. Here are the arguments that my diff3 batch files receives: (These arguments seem to follow the GNU diff3 argument style.) 1) -E 2) -m 3) -L 4) .working 5) -L 6) .merge-left.rOLD_REVISION 7) -L 8) .merge-right.rYOUR_REVISION 9) /full/path/to/MYFILE 10) /full/path/to/OLDFILE 11) /full/path/to/YOURFILE In the above argument list, the -L values are not descriptive enough. Can we add the filename as a prefix? Example: .working - MYFILE.working Such that, if MYFILE = biglib.c, then .working - biglib.c.working Many thanks, Kevin Connor Arpe Hongkong This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. PLEASE NOTE THAT WE HAVE MOVED. Our new address is 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. Our new telephone number is +44 (0) 20 3535 8300. This e-mail and its attachments are confidential. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although RI3K believes this e-mail and any attachments to be free of any virus or other defect which may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and RI3K does not accept any responsibility for any loss or damage in any way from its use. RI3K Limited is a company registered in England no: 3909745. Registered office 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. VAT registration no: 769 0192 07 PLEASE NOTE THAT WE HAVE MOVED. Our new address is 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. Our new telephone number is +44 (0) 20 3535 8300. This e-mail and its attachments are confidential. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although RI3K believes this e-mail and any attachments to be free of any virus or other defect which may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and RI3K does not accept any responsibility for any loss or damage in any way from its use. RI3K Limited is a company registered in England no: 3909745. Registered office 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. VAT registration no: 769 0192 07
AW: My Backup Script
Hi, Von: Andy Canfield [mailto:andy.canfi...@pimco.mobi] And make /backup a separate filesystem, preferably on a different host or some disk storage that runs independently from the host. In Linux a separate filesystem is often another partition on the hard disk, and thus not to be trusted too much. For safety an external hard disk, flushed, should be good enough. No need for an entire other host. Yes? Only if the external hard disk is only connected via fibre optics cable (SAS or similar) instead of copper cable. Electrical surges and short-cirquit faults tend to kill the server and the attached hard disks at the same time. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Moving Repositories to New server
Are there any know issues with regards to moving Repositories from one platform to another ? Will the old Repositories maintain their current SVN revision ? Current platform Sun Solaris 10: SVN 1.6.5 Target platform Red Hat Enterprise 5 SVN 1.6.17 ( Subversion Edge ) Planned steps (Creating a script for the dumps and loads as there as a few hundred Repositories to move.) (1) Freeze the repository . Take a dump of the repository. (2) Verify the file is dumped correctly by making sure that the last version dumped is the same as the one in the live repository. Also check the return code of the svnadmin dump command. (3) Copy the dump file over to the new server. Verify that the file is copied over correctly. (4) Load the dump (5) Verify the load. (6) Migrate and hook scripts or authorization files over. (7) Verify the scripts and configuration files work. (8) If you have a name for the server for accessing it. You might have to point the name to the new server. a. use switch ? b. or relocate ? (9) Unfreeze the repository. Questions : Switch vs relocate ? Effects of load into a new Subversion version ? -- The fundamental principle here is that the justification for a physical concept lies exclusively in its clear and unambiguous relation to the facts that it can be experienced AE Please Feed and Educate the Children... it's the least any of us can do.
Re: Moving Repositories to New server
Around about 26/07/11 15:35, Phil Pinkerton typed ... Questions : Switch vs relocate ? Effects of load into a new Subversion version ? That all sounds fine¹; you will need 'svn switch --relocate new-url' to maintain each existing working copy, as you surmised. The only thing you might have to watch out for above what you listed is that the new server has the same tool set that the old one does, so that the copied hook scripts still work. ¹ - However I have rarely done this myself :) -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 4:34 AM, Becker, Thomas thomas.bec...@torex.comwrote: Hi, ** ** I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet ( https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows). ** ** With the “alpha” and “beta” clients I get the following error: ** ** svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL ' https://:8443/' svn: E175009: XML parsing failed: (400 Bad Request) Does the SVN ls command even support this? I was not aware that it did. When I try it from OSX using 1.6 and 1.7 this is what I get: 1.6: $ /usr/bin/svn ls http://cu171.cloud.sp.collab.net/svn/ svn: Repository moved temporarily to 'http://cu171.cloud.sp.collab.net/svn/'; please relocate 1.7: $ svn ls http://cu171.cloud.sp.collab.net/svn/ svn: E175011: Unable to connect to a repository at URL ' http://cu171.cloud.sp.collab.net/svn' subversion/libsvn_ra_neon/util.c:607: (apr_err=175011) svn: E175011: Repository moved temporarily to ' http://cu171.cloud.sp.collab.net/svn'; please relocate In my case the server is running 1.7 as well. I can browse the list of repositories using my web browser. FWIW, that is all I thought this feature was supposed to support. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: How to clean the working dir from .svn folders ?
*From:* Geoff Hoffman ghoff...@cardinalpath.com *Sent:* Tuesday, July 26, 2011 4:05 PM *To:* users@subversion.apache.org *Subject:* Re: How to clean the working dir from .svn folders ? I believe you can use a bash script similar to the following, but you may need to set a flag from PHP so that cron running as root or admin has permission to delete them. Hope it helps- #!/bin/sh echo recursively removing .svn folders from pwd rm -rf `find . -type d -name .svn` On Tue, Jul 26, 2011 at 7:32 AM, Damien Mistic mistic100.fore...@hotmail.fr wrote: ‘rm’ is a not a Windows function, as I said I must run on all platforms, that’s why it’s better if subversion can do it itself [image: Sourire] Damien. Ah - I thought someone mentioned cygwin ... sorry. Could you create a PHP script specifically for this? There are lots of recursive directory walk scripts online. I'm sure you have a reason why svn export won't work but are you certain? That's what it's for. You can't export as 'original-dir-export' next to your original-dir, delete the original-dir, rename the exported back to same as original-dir? wlEmoticon-smile[1].png Description: Binary data
Re: How to clean the working dir from .svn folders ?
*From:* Geoff Hoffman ghoff...@cardinalpath.com *Sent:* Tuesday, July 26, 2011 4:05 PM *To:* users@subversion.apache.org *Subject:* Re: How to clean the working dir from .svn folders ? I believe you can use a bash script similar to the following, but you may need to set a flag from PHP so that cron running as root or admin has permission to delete them. Hope it helps- #!/bin/sh echo recursively removing .svn folders from pwd rm -rf `find . -type d -name .svn` On Tue, Jul 26, 2011 at 7:32 AM, Damien Mistic mistic100.fore...@hotmail.fr wrote: ‘rm’ is a not a Windows function, as I said I must run on all platforms, that’s why it’s better if subversion can do it itself [image: Sourire] Damien. Ah - I thought someone mentioned cygwin ... sorry. Could you create a PHP script specifically for this? There are lots of recursive directory walk scripts online. I'm sure you have a reason why svn export won't work but are you certain? That's what it's for. You can't export as 'original-dir-export' next to your original-dir, delete the original-dir, rename the exported back to same as original-dir? On Tue, Jul 26, 2011 at 8:04 AM, Damien Mistic mistic100.fore...@hotmail.fr wrote: Dir you read my first mail ? I repost it here : Hi all, so my problem is clear : I've a working dir and I want to clean it up from all .svn folders, how to ? Knowing that I'm working un CLI within exec() function of PHP. Unfortunately I can't delete manually files and folders : Warning: unlink(svn/.svn/all-wcprops) [function.unlink]: Permission denied in C:\wamp\www\lang_editor\include\functions.inc.php on line 325 And the 'export' function is not what I want because my aim is to delete the folder, not really get a clean copy. If there is no way I think we must add a new function to SVN, such as 'svn unlink' or 'svn dissociate' Regards, Damien. Yes, I read it, but I don't understand *why* export-and-rename won't work as the end result would be indistinguishable from what you're saying you want. You may be able to run PHP script with admin user rights on the command line but it's different across platforms how to do this. Sorry I'm not more help. wlEmoticon-smile[1].png Description: Binary data
Re: Moving Repositories to New server
On Tue, Jul 26, 2011 at 10:35:02AM -0400, Phil Pinkerton wrote: Are there any know issues with regards to moving Repositories from one platform to another ? Will the old Repositories maintain their current SVN revision ? Current platform Sun Solaris 10: SVN 1.6.5 Target platform Red Hat Enterprise 5 SVN 1.6.17 ( Subversion Edge ) Planned steps (Creating a script for the dumps and loads as there as a few hundred Repositories to move.) (1) Freeze the repository . Take a dump of the repository. (2) Verify the file is dumped correctly by making sure that the last version dumped is the same as the one in the live repository. Also check the return code of the svnadmin dump command. (3) Copy the dump file over to the new server. Verify that the file is copied over correctly. (4) Load the dump (5) Verify the load. If your repositories are in FSFS format (check the file db/fs-type) you don't need to perform a dump/load cycle. It doesn't hurt, but it can take longer than copying the repositories directly. Run 'svnadmin verify' on all repositories before you start moving them. If all is good, disable commit, and run 'svnadmin verify' again for revisions you didn't have in the previous run (see the -r option). Then use 'svnadmin hotcopy' to copy the repository to a disk, transfer it to the new server, run 'svnadmin verify' on it again, and enable commit at the new location. (6) Migrate and hook scripts or authorization files over. 'svnadmin hotcopy' will copy all files in a repository (except versions prior to 1.6.11 which do not copy db/conf/fsfs.conf because of a bug). (7) Verify the scripts and configuration files work. (8) If you have a name for the server for accessing it. You might have to point the name to the new server. a. use switch ? b. or relocate ? You need relocate (on the 1.6.x command line, this is confusingly called 'svn switch --relocate') if the hostname or the access protocol (http://, svn:// etc.) of your new server is not the same as the old one.
Question about commit/udpate inside externals
Hello list, I have a repository which contains an external to another repository with a fixed revision number. Something like: -rxxx svn+ssh://... I noticed I can make modifications inside this external and commit the modifications. At which point the external is actually above its fixed revision number (xxx+1 for example). svn status does not mention this particular state and svn up does not bring the external back to its fixed revision number. What bothers my is that doing a checkout of the repository will get me to a different state but doing svn status and svn up on my working copy does not alert me of that. How can I check if my externals are above their fixed revision number? Maybe it is just a bad idea to edit and commit inside externals? Regards, Thomas
Re: My Backup Script
On 7/26/2011 7:48 AM, Andy Canfield wrote: As I understand Subversion, [a] The server has no idea who has a working copy. [b] The checkout builds a working copy on the workstation from the server's repository. [c] What is on the developers hard disk is a working copy. [d] What is on the developer's hard disk continues to be a working copy, even after a commit. Yes, but it is then a mixed rev and needs an update. That is, the changes you committed belong to the rev the commit creates while the unchanged files belong to the rev of the prior update or checkout. [e] If the developer tries to make revisions to his working copy six months after his last commit, then tries to commit, he's going to have a major mess on his hands trying to reconcile things. The working copy is still a valid working copy. Normally you would do an update to pick up and reconcile other changes, then commit. [f] Unlike a lock, which he grabs and then releases, he never gives up his working copy; it is valid perpetually. But, in the context of backups, note that you can only commit to the repository where the checkout originated (determined by uuid) and the revision of the repo can't go backwards. So, if you restore a backup older than the rev of your working copy's checkout or last update you won't be able to commit the changes from that working copy. The only reasonable approach to doing that would be to check out the closest match from what is currently in the restored repo, copy over your changed files, and then commit. This could be cumbersome with a large tree with many changes. -- Les Mikesell lesmikes...@gmail.com
Re: Moving Repositories to New server
On 26/07/11 15:35, Phil Pinkerton wrote: Are there any know issues with regards to moving Repositories from one platform to another ? Will the old Repositories maintain their current SVN revision ? Current platform Sun Solaris 10: SVN 1.6.5 Target platform Red Hat Enterprise 5 SVN 1.6.17 ( Subversion Edge ) Planned steps (Creating a script for the dumps and loads as there as a few hundred Repositories to move.) (1) Freeze the repository . Take a dump of the repository. (2) Verify the file is dumped correctly by making sure that the last version dumped is the same as the one in the live repository. Also check the return code of the svnadmin dump command. (3) Copy the dump file over to the new server. Verify that the file is copied over correctly. (4) Load the dump (5) Verify the load. (6) Migrate and hook scripts or authorization files over. (7) Verify the scripts and configuration files work. (8) If you have a name for the server for accessing it. You might have to point the name to the new server. a. use switch ? b. or relocate ? (9) Unfreeze the repository. Questions : Switch vs relocate ? Effects of load into a new Subversion version ? To minimise down-time I would suggest looking into using svnsync to create the new repository, I think something on the following lines should work 1. create the new repository and sync it with the master one 2. copy over the hooks and scripts 3. inform all users that the old repository is not available any longer and any commit will not work and possibly be lost 4. lock down the master repository. This may just be stopping Apache serving it, nothing drastic, like removing it, is neceserry yet. Besides, it's safer to keep it just in case 5. set the new repository as master. This involves deleting some revision properties on revision 0 that Subversion uses to sync the repository. As the new repository will not be synced any more these are no more necessary. Moreover, they will prevent the repository to work as a normal one rather than a synchronised copy. 6. inform all users to use svn switch --relocate to point their WCs to the new repository As you can see the old repository comes down only at step 4, and steps 5 takes only few seconds. I used this set-up for my DR solution. I had never had the chance to use it, but I did some testing and it seemed to work. Giulio
Re: How to clean the working dir from .svn folders ?
On 7/26/2011 9:58 AM, Geoff Hoffman wrote: Ah - I thought someone mentioned cygwin ... sorry. Could you create a PHP script specifically for this? There are lots of recursive directory walk scripts online. I'm sure you have a reason why svn export won't work but are you certain? That's what it's for. You can't export as 'original-dir-export' next to your original-dir, delete the original-dir, rename the exported back to same as original-dir? Another reasonable alternative is to update a working copy in a staging area, possibly on a test server, then use rsync with the '-C' option to copy the files into their production location(s). That option skips files associated with svn or cvs metadata (and a few other things so it is best to look at the list it skips before trusting it). -- Les Mikesell lesmikes...@gmail.com
Re: Question about commit/udpate inside externals
On Tue, Jul 26, 2011 at 8:08 AM, Thomas Clement tclement...@gmail.comwrote: Hello list, I have a repository which contains an external to another repository with a fixed revision number. Something like: -rxxx svn+ssh://... I noticed I can make modifications inside this external and commit the modifications. At which point the external is actually above its fixed revision number (xxx+1 for example). svn status does not mention this particular state and svn up does not bring the external back to its fixed revision number. What bothers my is that doing a checkout of the repository will get me to a different state but doing svn status and svn up on my working copy does not alert me of that. How can I check if my externals are above their fixed revision number? Maybe it is just a bad idea to edit and commit inside externals? Regards, Thomas Subversion will let you do this, because for others it may be desired. As with most things, it depends on your use case. We had a similar one as yours. You may want to set a tag for your externals, then yes, don't work on it (don't commit to it). Have your external directory to also have trunk, tags, branches. Work on the trunk in a separate area. Tag it. Set your working copies to reference this tag. It's an easy thing to mess up. Most IDE's will alert you upon commit that you are committing to multiple branches...
Re: Moving Repositories to New server
On 7/26/2011 8:08 AM, Stefan Sperling wrote: On Tue, Jul 26, 2011 at 10:35:02AM -0400, Phil Pinkerton wrote: Are there any know issues with regards to moving Repositories from one platform to another ? Will the old Repositories maintain their current SVN revision ? Current platform Sun Solaris 10: SVN 1.6.5 Target platform Red Hat Enterprise 5 SVN 1.6.17 ( Subversion Edge ) snip If your repositories are in FSFS format (check the file db/fs-type) you don't need to perform a dump/load cycle. It doesn't hurt, but it can take longer than copying the repositories directly. If the processor architectures differ, copying the repositories directly won't work unless changes to the repository format have been made recently. I had a problem when copying a repository from a 64-bit x86 machine to a 32-bit x86 machine, for example. (I think this was in 1.4.x, but it was years ago and I don't remember the details.) Solaris 10 suggests a SPARC machine as the source. Because of the byte ordering difference, I'd expect major trouble when copying a repository directly from a SPARC machine to an x86 machine. I've used (and recommend) the svnsync approach recommended by another poster. Downtime can be even less than when copying repository directories directly. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: Question about commit/udpate inside externals
On Tue, Jul 26, 2011 at 05:08:52PM +0200, Thomas Clement wrote: Hello list, I have a repository which contains an external to another repository with a fixed revision number. Something like: -rxxx svn+ssh://... I noticed I can make modifications inside this external and commit the modifications. At which point the external is actually above its fixed revision number (xxx+1 for example). svn status does not mention this particular state and svn up does not bring the external back to its fixed revision number. What bothers my is that doing a checkout of the repository will get me to a different state but doing svn status and svn up on my working copy does not alert me of that. How can I check if my externals are above their fixed revision number? Maybe it is just a bad idea to edit and commit inside externals? Regards, Thomas See this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3401 and the discussion thread linked from it: http://svn.haxx.se/dev/archive-2009-04/0366.shtml
Re: Moving Repositories to New server
On Tue, Jul 26, 2011 at 08:35:31AM -0700, David Chapman wrote: If the processor architectures differ, copying the repositories directly won't work unless changes to the repository format have been made recently. I had a problem when copying a repository from a 64-bit x86 machine to a 32-bit x86 machine, for example. (I think this was in 1.4.x, but it was years ago and I don't remember the details.) Solaris 10 suggests a SPARC machine as the source. Because of the byte ordering difference, I'd expect major trouble when copying a repository directly from a SPARC machine to an x86 machine. This only applies to repositories using the BDB backend. There is no such problem with the FSFS backend because it uses flat files. I've used (and recommend) the svnsync approach recommended by another poster. Downtime can be even less than when copying repository directories directly. Yes, it's another good alternative. But don't forget to run 'svnadmin verify' on the synced copies, just to be safe.
AW: 1.7 compatibility issue
Sorry for the confusion: stands for svn/repo_name, stands for server_host. The URL looks like https://server_host:8443/svn/repo_name. Regards, Thomas Von: Mark Phippard [mailto:markp...@gmail.com] Gesendet: Dienstag, 26. Juli 2011 16:54 An: Becker, Thomas Cc: users@subversion.apache.org Betreff: Re: 1.7 compatibility issue On Tue, Jul 26, 2011 at 4:34 AM, Becker, Thomas thomas.bec...@torex.com wrote: Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn _binaries.windows ). With the alpha and beta clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' svn: E175009: XML parsing failed: (400 Bad Request) Does the SVN ls command even support this? I was not aware that it did. When I try it from OSX using 1.6 and 1.7 this is what I get: 1.6: $ /usr/bin/svn ls http://cu171.cloud.sp.collab.net/svn/ svn: Repository moved temporarily to 'http://cu171.cloud.sp.collab.net/svn/'; please relocate 1.7: $ svn ls http://cu171.cloud.sp.collab.net/svn/ svn: E175011: Unable to connect to a repository at URL 'http://cu171.cloud.sp.collab.net/svn' subversion/libsvn_ra_neon/util.c:607: (apr_err=175011) svn: E175011: Repository moved temporarily to 'http://cu171.cloud.sp.collab.net/svn'; please relocate In my case the server is running 1.7 as well. I can browse the list of repositories using my web browser. FWIW, that is all I thought this feature was supposed to support. -- Thanks Mark Phippard http://markphip.blogspot.com/ This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
Re: AW: My Backup Script
On Tue, 26 Jul 2011 16:11:27 +, Markus Schaber wrote: ... Von: Andy Canfield [mailto:andy.canfi...@pimco.mobi] ... disk, and thus not to be trusted too much. For safety an external hard disk, flushed, should be good enough. No need for an entire other host. Yes? Only if the external hard disk is only connected via fibre optics cable (SAS or similar) instead of copper cable. Electrical surges and short-cirquit faults tend to kill the server and the attached hard disks at the same time. Only if the disk is connected to a different power source, otherwise it doesn't much matter whether it's killed via data cable or power supply. (Also, this will in most cases only kill the drive electronics; there is still the possibility to have the driver platter to be installed into another drive, by professional recovery services.) But the simplest ist to disconnect the external drive and to use two or three in cycles (if that hadn't been mentioned here), and take the others home or another location different from the servers's. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Moving Repositories to New server
On 7/26/2011 10:44 AM, Stefan Sperling wrote: On Tue, Jul 26, 2011 at 08:35:31AM -0700, David Chapman wrote: If the processor architectures differ, copying the repositories directly won't work unless changes to the repository format have been made recently. I had a problem when copying a repository from a 64-bit x86 machine to a 32-bit x86 machine, for example. (I think this was in 1.4.x, but it was years ago and I don't remember the details.) Solaris 10 suggests a SPARC machine as the source. Because of the byte ordering difference, I'd expect major trouble when copying a repository directly from a SPARC machine to an x86 machine. This only applies to repositories using the BDB backend. There is no such problem with the FSFS backend because it uses flat files. I've used (and recommend) the svnsync approach recommended by another poster. Downtime can be even less than when copying repository directories directly. Yes, it's another good alternative. But don't forget to run 'svnadmin verify' on the synced copies, just to be safe. In a situation where copying directly will work, you can use 'rsync -a' to copy the live repositories and do the bulk of the work with the old system still active. Then when ready to cut over, stop svnserve/http access and repeat the command with the --delete option. That will complete quickly because it only has to duplicate the changes since the previous run. -- Les Mikesell lesmikes...@gmail.com
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 11:44 AM, Becker, Thomas thomas.bec...@torex.comwrote: Sorry for the confusion: stands for svn/repo_name, stands for server_host. The URL looks like https:// server_host:8443/svn/repo_name. So you are saying you cannot even do svn ls against a repository? The automated test suite would exercise that. It could be some incompatibility between the client binaries and the way VisualSVN configures authentication or something like that. The binaries are probably using ra_serf to talk to the repository, which is new in 1.7. You can try configuring your client to use Neon as the default. Edit %APPDATA%\Subversion\config and add: http-library = neon At the bottom. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 13:37, Becker, Thomas thomas.bec...@torex.com wrote: Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas Could you please try to add explicit ServerName configuration directive to %VISUALSVN_SERVER%\conf\httpd-custom.conf file and restart the server: ServerName :8443 -- Ivan Zhakov
Re: How to clean the working dir from .svn folders ?
On Tue, Jul 26, 2011 at 9:27 AM, Damien Mistic mistic100.fore...@hotmail.fr wrote: And I maintain the final aim is absolutely not the same as ‘export’ does. If you say so. I'm not sure how that could be possible given my understanding of the svn export command. Anyway, glad you got it sorted out!
Re: My Backup Script
On Tue, 26 Jul 2011 10:09:47 +, Les Mikesell wrote: ... Yes, but it is then a mixed rev and needs an update. That is, the changes you committed belong to the rev the commit creates while the unchanged files belong to the rev of the prior update or checkout. This is one of the high strangitude svn behaviour artefacts: That you can't do two consecutive commits without getting an error (in some relatively popular cases). Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 20:25, Ivan Zhakov i...@visualsvn.com wrote: On Tue, Jul 26, 2011 at 13:37, Becker, Thomas thomas.bec...@torex.com wrote: Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas Could you please try to add explicit ServerName configuration directive to %VISUALSVN_SERVER%\conf\httpd-custom.conf file and restart the server: ServerName :8443 I was able to reproduce the issue in my environment. It seems to be bug in ra_serf/serf code: it sets SNI hostname to 'hostname:port', while valid value is 'hostname' (without port). So currently there're two workaround possible: 1. Use neon as http-library on client 2. Use default HTTPS port (443) on server -- Ivan Zhakov
Re: Moving Repositories to New server
On Tue, Jul 26, 2011 at 09:22:04AM -0700, David Chapman wrote: On 7/26/2011 8:44 AM, Stefan Sperling wrote: On Tue, Jul 26, 2011 at 08:35:31AM -0700, David Chapman wrote: If the processor architectures differ, copying the repositories directly won't work unless changes to the repository format have been made recently. I had a problem when copying a repository from a 64-bit x86 machine to a 32-bit x86 machine, for example. (I think this was in 1.4.x, but it was years ago and I don't remember the details.) Solaris 10 suggests a SPARC machine as the source. Because of the byte ordering difference, I'd expect major trouble when copying a repository directly from a SPARC machine to an x86 machine. This only applies to repositories using the BDB backend. There is no such problem with the FSFS backend because it uses flat files. The bad copy was a FSFS repository. IIRC, the problem was writing binary data (e.g. integers) into files. The 64-bit machine wrote 64-bit integers into some of the files, and the 32-bit machine got confused. I don't think there are any platform dependent bits in an FSFS revision file itself. It's much like you can copy, say, a PDF document or a jpg image via the network from one platform to another and have it work. Mounting a big-endian filesystem that was written on a sparc on an x86 box is of course a different story. It might work, or it might not. There is nothing an application can do to account for that though. It would be good to know what really went wrong in your case. Maybe something went wrong during the copy process? How was the repository transferred? Over the network (good idea), or via a disk that used a big-endian filesystem (possibly a bad idea if the x86 box has no support for reading it properly despite the byte ordering difference)? Unless FSFS writes no binary data into its files, or else it is careful to do so in a platform-independent matter, there will be trouble. Not being an official Subversion developer, I can't comment on the internals of the FSFS format, but I would be very surprised if its files were truly platform-independent because this would slow down repository operations. See the spec here if you want to know the details: https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure Some related links: https://svn.apache.org/repos/asf/subversion/trunk/notes/svndiff https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/structure (BDB spec) https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history Given that there is an official portable transfer file format (the dump file), I would expect the Subversion developers to use more-efficient non-portable code within the repository files. It is more about being able to switch between backends and to allow upgrades to versions that change the repository format in non-trivial ways. You can certainly try to copy one repository directly from one platform to the other, then run svnadmin verify. That *should* tell you if there was a problem. Yes, indeed. But I wouldn't trust anything worth money on an inter-platform repository file copy. I suppose it depends on how that copy is done.
Re: My Backup Script
On 7/26/2011 11:42 AM, Andreas Krey wrote: On Tue, 26 Jul 2011 10:09:47 +, Les Mikesell wrote: ... Yes, but it is then a mixed rev and needs an update. That is, the changes you committed belong to the rev the commit creates while the unchanged files belong to the rev of the prior update or checkout. This is one of the high strangitude svn behaviour artefacts: That you can't do two consecutive commits without getting an error (in some relatively popular cases). And you generally shouldn't be doing that unless there is some special need to avoid picking up concurrent changes (and if it were handled automatically, you wouldn't be able to). -- Les Mikesell lesmikes...@gmail.com
Re: Moving Repositories to New server
Phil Pinkerton pcpinker...@gmail.com wrote on 07/26/2011 09:35:02 AM: Are there any know issues with regards to moving Repositories from one platform to another ? Will the old Repositories maintain their current SVN revision ? Current platform Sun Solaris 10: SVN 1.6.5 Target platform Red Hat Enterprise 5 SVN 1.6.17 ( Subversion Edge ) Planned steps (Creating a script for the dumps and loads as there as a few hundred Repositories to move.) (1) Freeze the repository . Take a dump of the repository. (2) Verify the file is dumped correctly by making sure that the last version dumped is the same as the one in the live repository. Also check the return code of the svnadmin dump command. (3) Copy the dump file over to the new server. Verify that the file is copied over correctly. (4) Load the dump (5) Verify the load. (6) Migrate and hook scripts or authorization files over. (7) Verify the scripts and configuration files work. (8) If you have a name for the server for accessing it. You might have to point the name to the new server. a. use switch ? b. or relocate ? (9) Unfreeze the repository. As others have stated there are multiple ways. Be careful if your users use file locking, since most of the options will ignore lock tokens. (Just as most of the options ignore hook scripts and authorization files.) I've gone from Red Hat 3 to Solaris 10 (both x64) by just rsyncing the fsfs filesystem. (It is best to ignore transactions and sync the current file first if you plan on doing the initial rsync with a live database.) I've gone from Win 2003 x86 to Win 2008 x64 by svnsync. I've gone from Solaris to Windows using dumpfiles. I've gone from Windows to Red Hat with svnsync. I've played with hot copies, but not used them for much. They all have worked. Dumpfiles are by far the slowest and will take considerable temporary space if you have repositories of any significant size. However, I would consider dumpfiles the safest since you essentially will have a complete separate portable copy of the whole repository. (minus locks, hooks, and auth stuff mentioned above.) svnsync can also be quite slow, but would probably require less downtime since you can sync and re-sync live repositories. (Just make sure you either have rev-prop changing disabled or have a way to identify already sync'd rev-prop changes.) Kevin R.
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 20:45, Ivan Zhakov i...@visualsvn.com wrote: On Tue, Jul 26, 2011 at 20:25, Ivan Zhakov i...@visualsvn.com wrote: On Tue, Jul 26, 2011 at 13:37, Becker, Thomas thomas.bec...@torex.com wrote: Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas Could you please try to add explicit ServerName configuration directive to %VISUALSVN_SERVER%\conf\httpd-custom.conf file and restart the server: ServerName :8443 I was able to reproduce the issue in my environment. It seems to be bug in ra_serf/serf code: it sets SNI hostname to 'hostname:port', while valid value is 'hostname' (without port). So currently there're two workaround possible: 1. Use neon as http-library on client 2. Use default HTTPS port (443) on server Fixed in r1151177 and nominated for backport to 1.7.x. Thanks for bug report! -- Ivan Zhakov
Re: svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
Or to state the below (pardon the top-post) much more simply: the --trust-server-cert flag does not work. It fails to perform its singular function, which is...to force trust of the server cert, right? (Though I still think something else is going on, I can start there). On Mon, Jul 25, 2011 at 1:12 PM, Dan Yost yod...@gmail.com wrote: Greetings, I'm at my wit's end trying to debug a troubling, highly irregular issue connecting to a SVN server via HTTPS. I am very confident this is a client issue, not a server issue. The server is CollabNet's Subversion Edge server, which has 1.6.15 built in. The client is 1.6.15 running under Cygwin. I have many, many clients, most of which are running Windows Server 2003 (if that matters)--all Cygwin, all this same package. Lots of traffic every day. Almost all of it works just fine. Now, a very important fact: the svn operations WORK 95% of the time. They just work. Everything is absolutely fine. This is an unattended, fully-automated environment, launched from cron (well, Task Scheduler when running on these Windows boxes). 95% of the time, the job launches, runs my svn update command from within one of its working copies: svn update --username=some --password=thing --non-interactive and it works beautifully. Every once in awhile, for absolutely no reason I can find (have looked at logs, logs, logs, timing, the stars and planets, everything), with absolutely nothing that I can find having changed, it dies with this: svn: OPTIONS of 'https://myserver:/svn/some/path': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://myserver:) (I have changed the paths/ports to protect the innocent). Now for most of my clients, the issued for a different hostname part is omitted--they still have the issuer not trusted part. That's because my one host that I'm really digging in to debug this has to use a different hostname for certain reasons. So, focus on the issuer not trusted part because that's what we see across all clients. But keep in mind: it works. It works 95% of the time. I change absolutely nothing. Having found no indication of why it will *randomly* fail with the above error, I decided to add the --trust-cerver-cert flag, thinking surely this will eliminate all woes. Just trust it and go (trust it like you already do 95% of the time anyway)! svn update --username=some --password=thing --non-interactive --trust-server-cert But, nope, I randomly get the very same error. These key facts: 1) It works 95% of the time (well, maybe 85%) 2) I can find NOTHING changing (on client or server) between a working op and a breaking op--it's all automated, and just randomly shanks are leading me to believe that this error message is actually a complete wild goose chase, and that the problem is not actually cert-based but is something else (with a wrong error message). In looking at the server HTTP logs, it does indeed appear that the client bails out before continuing the connection--there's no log, meaning it does appear that the client can't handshake (or refuses to), and then quits. I have thought about adding options to config (on the command line) such as ssl-trust-default-ca, but again, I already told svn to --trust-server-cert and it randomly still dies, so I don't think that will help. You'll be tempted to focus on SSL cert issues on the server or something, but remember that we don't change anything and it works fine almost all the time! (I'm still open to any thoughts of course). Can anybody point me to some other debug options, some other flag, or any other way to determine why, 15% of the time, it dies, yet 85% of the time it updates just fine? Thanks, Dan
Re: Moving Repositories to New server
On 7/26/2011 9:48 AM, Stefan Sperling wrote: On Tue, Jul 26, 2011 at 09:22:04AM -0700, David Chapman wrote: On 7/26/2011 8:44 AM, Stefan Sperling wrote: On Tue, Jul 26, 2011 at 08:35:31AM -0700, David Chapman wrote: If the processor architectures differ, copying the repositories directly won't work unless changes to the repository format have been made recently. I had a problem when copying a repository from a 64-bit x86 machine to a 32-bit x86 machine, for example. (I think this was in 1.4.x, but it was years ago and I don't remember the details.) Solaris 10 suggests a SPARC machine as the source. Because of the byte ordering difference, I'd expect major trouble when copying a repository directly from a SPARC machine to an x86 machine. This only applies to repositories using the BDB backend. There is no such problem with the FSFS backend because it uses flat files. The bad copy was a FSFS repository. IIRC, the problem was writing binary data (e.g. integers) into files. The 64-bit machine wrote 64-bit integers into some of the files, and the 32-bit machine got confused. I don't think there are any platform dependent bits in an FSFS revision file itself. It's much like you can copy, say, a PDF document or a jpg image via the network from one platform to another and have it work. Mounting a big-endian filesystem that was written on a sparc on an x86 box is of course a different story. It might work, or it might not. There is nothing an application can do to account for that though. It would be good to know what really went wrong in your case. Maybe something went wrong during the copy process? How was the repository transferred? Over the network (good idea), or via a disk that used a big-endian filesystem (possibly a bad idea if the x86 box has no support for reading it properly despite the byte ordering difference)? The original copy was over a local area network, using tar cf - | ssh on the 64-bit machine and pushing the files to the 32-bit machine. My notes then say something to the effect of trouble - redone with dump and load cycle. This was in January 2007 with Subversion 1.3.0 on both ends. I never tried the directory copy again. I don't have better notes about what problems I found. The FSFS spec links are interesting and on first reading suggest portability, but I don't have enough time to study them in detail. I'd have to look at all of the specs for repository files to be sure. For now I back up my repositories nightly using hot copies and full dumps (about 2 GB total dump size, so still feasible). One of the repositories came from a remote hosting service via svnsync; we decided that local hosting was better. I don't use svnsync locally now because all but one of my machines are powered off at night, but it worked without any problems then. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: My Backup Script
On Tue, 26 Jul 2011 11:53:15 +, Les Mikesell wrote: On 7/26/2011 11:42 AM, Andreas Krey wrote: ... This is one of the high strangitude svn behaviour artefacts: That you can't do two consecutive commits without getting an error (in some relatively popular cases). And you generally shouldn't be doing that unless there is some special need to avoid picking up concurrent changes No, there are no concurrent changes. I'm the only one working the repo; For the second of the back-to-back commits I got the error, which is easily explained when you know about mixed revisions and that. But at the same time it looks utterly idiotic, since the WC was up to date before, so how can it possibly be not up to date after the first commit. Script: set -xe rm -rf repo wc svnadmin create repo svn checkout file:///`pwd`/repo wc cd wc mkdir D touch A D/B D/C E # svn add . # - That nuisance 'already under control'... svn add A D E svn commit -m 'initial' svn up date D/B date A svn propset blub blah . svn commit D -m green svn commit . -m blau And output (i'm on 1.6.6, however): + rm -rf repo wc + svnadmin create repo ++ pwd + svn checkout file:Users/andreaskrey/svnt/wc/repo wc Checked out revision 0. + cd wc + mkdir D + touch A D/B D/C E + svn add A D E A A A D A D/B A D/C A E + svn commit -m initial Adding A Adding D Adding D/B Adding D/C Adding E Transmitting file data Committed revision 1. + svn up At revision 1. + date + date + svn propset blub blah . property 'blub' set on '.' + svn commit D -m green SendingD/B Transmitting file data . Committed revision 2. + svn commit . -m blau Sending. svn: Commit failed (details follow): svn: Directory '/' is out of date Andreas
Re: svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
Dan Yost wrote on Tue, Jul 26, 2011 at 12:57:29 -0500: Or to state the below (pardon the top-post) much more simply: the --trust-server-cert flag does not work. It fails to perform its singular function, which is...to force trust of the server cert, right? Its function is to accept certificates signed by unknown CA's without prompting. In your case you have two failures, one of them being the mismatching subject name (hostname), so you do get prompted. (Though I still think something else is going on, I can start there). On Mon, Jul 25, 2011 at 1:12 PM, Dan Yost yod...@gmail.com wrote: Greetings, I'm at my wit's end trying to debug a troubling, highly irregular issue connecting to a SVN server via HTTPS. I am very confident this is a client issue, not a server issue. The server is CollabNet's Subversion Edge server, which has 1.6.15 built in. The client is 1.6.15 running under Cygwin. I have many, many clients, most of which are running Windows Server 2003 (if that matters)--all Cygwin, all this same package. Lots of traffic every day. Almost all of it works just fine. Now, a very important fact: the svn operations WORK 95% of the time. They just work. Everything is absolutely fine. This is an unattended, fully-automated environment, launched from cron (well, Task Scheduler when running on these Windows boxes). 95% of the time, the job launches, runs my svn update command from within one of its working copies: svn update --username=some --password=thing --non-interactive and it works beautifully. Every once in awhile, for absolutely no reason I can find (have looked at logs, logs, logs, timing, the stars and planets, everything), with absolutely nothing that I can find having changed, it dies with this: svn: OPTIONS of 'https://myserver:/svn/some/path': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://myserver:) (I have changed the paths/ports to protect the innocent). Now for most of my clients, the issued for a different hostname part is omitted--they still have the issuer not trusted part. That's because my one host that I'm really digging in to debug this has to use a different hostname for certain reasons. So, focus on the issuer not trusted part because that's what we see across all clients. But keep in mind: it works. It works 95% of the time. I change absolutely nothing. Having found no indication of why it will *randomly* fail with the above error, I decided to add the --trust-cerver-cert flag, thinking surely this will eliminate all woes. Just trust it and go (trust it like you already do 95% of the time anyway)! svn update --username=some --password=thing --non-interactive --trust-server-cert But, nope, I randomly get the very same error. These key facts: 1) It works 95% of the time (well, maybe 85%) 2) I can find NOTHING changing (on client or server) between a working op and a breaking op--it's all automated, and just randomly shanks are leading me to believe that this error message is actually a complete wild goose chase, and that the problem is not actually cert-based but is something else (with a wrong error message). In looking at the server HTTP logs, it does indeed appear that the client bails out before continuing the connection--there's no log, meaning it does appear that the client can't handshake (or refuses to), and then quits. I have thought about adding options to config (on the command line) such as ssl-trust-default-ca, but again, I already told svn to --trust-server-cert and it randomly still dies, so I don't think that will help. You'll be tempted to focus on SSL cert issues on the server or something, but remember that we don't change anything and it works fine almost all the time! (I'm still open to any thoughts of course). Can anybody point me to some other debug options, some other flag, or any other way to determine why, 15% of the time, it dies, yet 85% of the time it updates just fine? Thanks, Dan
Re: svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
On Tue, Jul 26, 2011 at 2:19 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Dan Yost wrote on Tue, Jul 26, 2011 at 12:57:29 -0500: Or to state the below (pardon the top-post) much more simply: the --trust-server-cert flag does not work. It fails to perform its singular function, which is...to force trust of the server cert, right? Its function is to accept certificates signed by unknown CA's without prompting. In your case you have two failures, one of them being the mismatching subject name (hostname), so you do get prompted. Ah, so indeed perhaps this will reveal a key difference between my test client and the rest of the live clients (still gathering info on them to see if they continue to fail). The rest of the clients don't have the hostname issue, I believe, so perhaps they will indeed be improved by the flag. But, any idea why it works one minute, then doesn't the next, when nobody touches anything? Or, a good way to dig deeper? Perhaps I need a very verbose dump of the whole SSL handshake, I guess, to find out why it works fine one minute then doesn't the next, but I didn't find an option (particularly on the update subcommand). Thanks, Dan
Re: svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
On Tue, Jul 26, 2011 at 2:32 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Daniel Shahaf wrote on Tue, Jul 26, 2011 at 22:19:13 +0300: Dan Yost wrote on Tue, Jul 26, 2011 at 12:57:29 -0500: Or to state the below (pardon the top-post) much more simply: the --trust-server-cert flag does not work. It fails to perform its singular function, which is...to force trust of the server cert, right? Its function is to accept certificates signed by unknown CA's without prompting. In your case you have two failures, one of them being the mismatching subject name (hostname), so you do get prompted. See ssl_trust_unknown_server_cert() in subversion/libsvn_subr/cmdline.c. There were discussions about extending this to, for example, --trust-server-cert2=comma,separated,list,of,failures,to,ignore , and I think someone may have started working on a patch, but they never submitted it to us. A possibility, indeed. What's still very odd is that there's actually no error--nothing to ignore. That is, 95% of the time, then randomly (5%) it shanks, and nobody touched anything (on either server side or client side). That's what is making me crazy. Dan
Re: My Backup Script
On Tue, 26 Jul 2011 13:55:17 +, Les Mikesell wrote: ... How could it possibly be up to date if there has been a commit since the last time it was updated? Because the commit came from my WC. My WC was up to date before the commit, and the only things that change have been in my WC already, so there is no possible way my WC can not be up to date. Except that it 'forgets' to update the WC revision info, and requires a separate update for that. (But probably I'm too much in the whole-tree-mindset to see the problems when a commit paints new revisions outside the area it committed. There is no 'the' revision info.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
On Tue, Jul 26, 2011 at 3:11 PM, Geoff Hoffman ghoff...@cardinalpath.com wrote: Long shot here... this is probably off base, as I am not that experienced with lower-level SSL problems, but are you by chance using an issuer that provides an intermediary certificate? For example, to install an SSL cert from GoDaddy, you have to also include the gd_bundle.crt. The Wikipedia article below makes me wonder if there is just some network hiccups sometimes, trying to validate your certificate chain authority. From http://en.wikipedia.org/wiki/Intermediate_certificate_authorities If the certificate was not issued by a trusted CA, the connecting device (e.g., a web browser) will then check to see if the issuing CA of the certificate was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the device will usually display an error). Yes, and indeed this is a GoDaddy cert, with the bundle installed to keep the chain intact, so thus it does work that 95% of the time. I was thinking that the chain is all presented from the server to client in one fell swoop, with no need to go fetch anything else out there (not that you're suggesting that is what it needs to do--go outside to fetch something). But indeed, I suppose it could complicate the handshake in such a way as to cause this intermittent failure--would really like to be able to watch that happen via some kind of verbose log. Dan
Re: svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
On Tue, Jul 26, 2011 at 1:20 PM, Dan Yost yod...@gmail.com wrote: On Tue, Jul 26, 2011 at 3:11 PM, Geoff Hoffman ghoff...@cardinalpath.com wrote: Long shot here... this is probably off base, as I am not that experienced with lower-level SSL problems, but are you by chance using an issuer that provides an intermediary certificate? For example, to install an SSL cert from GoDaddy, you have to also include the gd_bundle.crt. The Wikipedia article below makes me wonder if there is just some network hiccups sometimes, trying to validate your certificate chain authority. From http://en.wikipedia.org/wiki/Intermediate_certificate_authorities If the certificate was not issued by a trusted CA, the connecting device (e.g., a web browser) will then check to see if the issuing CA of the certificate was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the device will usually display an error). Yes, and indeed this is a GoDaddy cert, with the bundle installed to keep the chain intact, so thus it does work that 95% of the time. I was thinking that the chain is all presented from the server to client in one fell swoop, with no need to go fetch anything else out there (not that you're suggesting that is what it needs to do--go outside to fetch something). But indeed, I suppose it could complicate the handshake in such a way as to cause this intermittent failure--would really like to be able to watch that happen via some kind of verbose log. Dan If this *might* be the problem, I'm guessing that browsers do a better job of trying again a few times than the svn client might. If you can simulate what your workflow is doing in Firefox with the LiveHeaders plugin, you can distill it down to a list of FQDNs that are required, then tracert them, ping them, etc., to see if you have any dropped packets. Also IPs are a straighter path than DNS names. It may not be easy for you to change everything around, but if you switched it all to IP-based you could rule out DNS being a problem.
Re: My Backup Script
On 7/26/2011 3:03 PM, Andreas Krey wrote: On Tue, 26 Jul 2011 13:55:17 +, Les Mikesell wrote: ... How could it possibly be up to date if there has been a commit since the last time it was updated? Because the commit came from my WC. My WC was up to date before the commit, and the only things that change have been in my WC already, so there is no possible way my WC can not be up to date. Except that it 'forgets' to update the WC revision info, and requires a separate update for that. It doesn't 'forget', it knows that doing it right would, in the general case, involve changing files in your working copy that you might not want to have changed. (But probably I'm too much in the whole-tree-mindset to see the problems when a commit paints new revisions outside the area it committed. There is no 'the' revision info.) While in this case you may 'know' that no one else has made any changes in the repository, but it is probably a bad idea to get into habits that won't work when you are part of a team. -- Les Mikesell lesmikes...@gmail.com
Re: Replacing symlink exhibits unexpected error
On 07/19/11 12:04, Mattius McLaughlin wrote: Hi All, I'm encountering some strange behaviour with replacing a symlink with a real file in the repository and wanted to know if what I was seeing is a bug or whether I'm doing something wrong. I'd like to replace the file in one commit, but Subversion objects to changing the file type: % ls -l trunk/memory_ddr3.v lrwxrwxrwx 1 mclaughl eng 74 Jul 19 11:51 trunk/memory_ddr3.v - /proj/ddr3/s39/s39a0c2762e5ac7f7 % svn status trunk/memory_ddr3.v % svn rm trunk/memory_ddr3.v D trunk/memory_ddr3.v % cp /proj/ddr3/s39/s39a0c2762e5ac7f7 trunk/memory_ddr3.v % svn add trunk/memory_ddr3.v A trunk/memory_ddr3.v % svn status trunk/memory_ddr3.v R trunk/memory_ddr3.v % svn ci -m Correcting link trunk/memory_ddr3.v svn: Commit failed (details follow): svn: Entry '/home/mclaughl/nobackup/trunk/memory_ddr3.v' has unexpectedly changed special status In case anyone stumbles across this later, the missing step here was to remove the svn:special property as well as removing the file: % ls -l trunk/memory_ddr3.v lrwxrwxrwx 1 mclaughl eng 74 Jul 19 11:51 trunk/memory_ddr3.v - /proj/ddr3/s39/s39a0c2762e5ac7f7 % svn status trunk/memory_ddr3.v % svn rm trunk/memory_ddr3.v D trunk/memory_ddr3.v % svn propdel svn:special trunk/memory_ddr3.v property 'svn:special' deleted from 'trunk/memory_ddr3.v'. % cp /proj/ddr3/s39/s39a0c2762e5ac7f7 trunk/memory_ddr3.v % svn add trunk/memory_ddr3.v A trunk/memory_ddr3.v % svn status trunk/memory_ddr3.v R trunk/memory_ddr3.v % svn ci -m Correcting link trunk/memory_ddr3.v Replacing trunk/memory_ddr3.v Transmitting file data . Committed revision 20311. I'm surprised the client can't handle this automatically, but I suppose it's a fairly rare use case. --Mattius McLaughlin
Re: Replacing symlink exhibits unexpected error
On Tue, Jul 26, 2011 at 02:10:59PM -0700, Mattius McLaughlin wrote: On 07/19/11 12:04, Mattius McLaughlin wrote: Hi All, I'm encountering some strange behaviour with replacing a symlink with a real file in the repository and wanted to know if what I was seeing is a bug or whether I'm doing something wrong. I'd like to replace the file in one commit, but Subversion objects to changing the file type: % ls -l trunk/memory_ddr3.v lrwxrwxrwx 1 mclaughl eng 74 Jul 19 11:51 trunk/memory_ddr3.v - /proj/ddr3/s39/s39a0c2762e5ac7f7 % svn status trunk/memory_ddr3.v % svn rm trunk/memory_ddr3.v D trunk/memory_ddr3.v % cp /proj/ddr3/s39/s39a0c2762e5ac7f7 trunk/memory_ddr3.v % svn add trunk/memory_ddr3.v A trunk/memory_ddr3.v % svn status trunk/memory_ddr3.v R trunk/memory_ddr3.v % svn ci -m Correcting link trunk/memory_ddr3.v svn: Commit failed (details follow): svn: Entry '/home/mclaughl/nobackup/trunk/memory_ddr3.v' has unexpectedly changed special status In case anyone stumbles across this later, the missing step here was to remove the svn:special property as well as removing the file: % ls -l trunk/memory_ddr3.v lrwxrwxrwx 1 mclaughl eng 74 Jul 19 11:51 trunk/memory_ddr3.v - /proj/ddr3/s39/s39a0c2762e5ac7f7 % svn status trunk/memory_ddr3.v % svn rm trunk/memory_ddr3.v D trunk/memory_ddr3.v % svn propdel svn:special trunk/memory_ddr3.v property 'svn:special' deleted from 'trunk/memory_ddr3.v'. % cp /proj/ddr3/s39/s39a0c2762e5ac7f7 trunk/memory_ddr3.v % svn add trunk/memory_ddr3.v A trunk/memory_ddr3.v % svn status trunk/memory_ddr3.v R trunk/memory_ddr3.v % svn ci -m Correcting link trunk/memory_ddr3.v Replacing trunk/memory_ddr3.v Transmitting file data . Committed revision 20311. I'm surprised the client can't handle this automatically, but I suppose it's a fairly rare use case. I can reproduce this problem in 1.6.x. I would say it is a bug. It seems to work fine in 1.7, without the need to delete the svn:special property first. There's a minor UI problem though, 'svn status' shows the replace as '~' rather than 'R'.
Re: My Backup Script
On Tue, 26 Jul 2011 15:59:59 +, Les Mikesell wrote: ... Because the commit came from my WC. My WC was up to date before the commit, and the only things that change have been in my WC already, so there is no possible way my WC can not be up to date. Except that it 'forgets' to update the WC revision info, and requires a separate update for that. It doesn't 'forget', it knows that doing it right would, in the general case, involve changing files in your working copy that you might not want to have changed. In what case? When svn lets me commit at all, it is when the WC is up to date; that is, there is nothing that needs to be merged into my WC. What files could need to be modified, under the assumption that the WC wasn't mixed-revision to begin with? ... While in this case you may 'know' that no one else has made any changes in the repository, but it is probably a bad idea to get into habits that won't work when you are part of a team. I seriously don't know what you mean here. If an 'svn up' wouldn't change anything in my WC before I do a commit, an 'svn up' immediately after my commit (to the revision I committed) wouldn't do either, and there is no reason why that shouldn't be reflected in the WC by the commit instead requiring me to do a separate update. In any case, there is always the chance of someone beating me to the commit, so I need to update beforehand. But that can happen before the first commit just as well. And for most cases two consecutive commits just work; I did need some time to come up with the scenario. Btw, is there a way to undo an update that lead to merges with my changes (or even conflicts), and get back my original modified sandbox? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: My Backup Script
On 07/27/2011 01:34 AM, Nico Kadel-Garcia wrote: On Tue, Jul 26, 2011 at 2:33 AM, Andy Canfieldandy.canfi...@pimco.mobi wrote: For your information, this is my backup script. It produces a zip file that can be tranported to another computer. The zip file unpacks into a repository collection, giving, for each repository, a hotcopy of the repository and a dump of the repository. The hotcopy can be reloaded on a computer with the same characteristics as the original server; the dumps can be loaded onto a different computer. Comments are welcome. Andy, can we love you to pieces for giving us a new admin to educate in subtleties? Sure! I'm good at being ignorant. FYI I have a BS in Computer Science about 1970 and an MS in Operations Research in 1972, worked in Silicon Valley until I moved to Thailand in 1990. So although I am not stupid, I can be very ignorant. And also the IT environment here is quite different. For example, MySQL can sync databases if you've got a 100Mbps link. Ha ha. I invented a way to sync two MySQL databases hourly over an unreliable link that ran at about modem speeds. I can remember making a driver climb a flagpole to make a cell phone call because the signal didn't reach the ground. To this day we run portable computers out in the field and communicate via floppynet. In this region hardware costs more than people, and software often costs nothing. #! /bin/bash # requires root access if [ ! `whoami` == root ] then sudo $0 exit fi # controlling parameters SRCE=/data/svn ls -ld $SRCE DEST=/data/svnbackup APACHE_USER=www-data APACHE_GROUP=www-data Unless the repository is only readable owned by root, this should *NOT* run as root. Seriously. Never do things as the root user that you don't have to. If the repository owner is svn or www-data as you've described previously, execute this as the relevant repository owner. There are reasonable justifications for running it as root: [1] Other maintenance scripts must be run as root, and this puts all maintenance in a central pool. My maintenance scripts are crontab jobs of the form /root/bin/TaskName.job which runs /root/bin/TaskName.sh and pipes all stderr and stdout to /root/TaskName.out. Thus I can skim /root/*.out and have all the job status information at my fingertips. [2] For some tasks, /root/bin/TaskName.job is also responsible for appending /root/TaskName.out to /root/TaskName.all so that I can see earlier outputs. There is a job that erases /root/*.all the first of every month. [3] I have heard for a long time never run GUI as root. None of these maintenance scripts are GUI. [4] There are many failure modes that will only arise if it is run as non-root. For example, if run as root, the command rm -rf /data/svnbackup will absolutely, for sure, get rid of any existing /data/svnbackup that exists, whoever it is owned by, whatever junk is inside it. # Construct a new empty SVNParent repository collection rm -rf $DEST mkdir $DEST chown $APACHE_USER $DEST chgrp $APACHE_GROUP $DEST chmod 0700 $DEST ls -ld $DEST And do. what? You've not actually confirmed that this has succeded unless you do something if these bits fail. Many of your comments seem to imply that this script has not been tested. Of course it's been tested already, and in any production environment it will be tested again. And if stdout and stderr are piped to /root/SVNBackup.out then I can check that output text reasonably often and see that it is still running. In this case I would check it daily for a week, weekly for a month or two, yearly forever, and every time somebody creates a new repository. Also, by the standards of this part of the world, losing a day's work is not a catastrophe. Most people can remember what they did, and do it again, and it probably only takes a half-day to redo. # Get all the names of all the repositories # (Also gets names of any other entry in the SVNParent directory) cd $SRCE ls -d1 */tmp/SVNBackup.tmp And *HERE* is where you start becoming a dead man id mkdir $DEST failed. I believe that it works in your current environment, but if the parent of $DEST does not exist, you're now officially in deep danger executing these operations in whatever directory the script was run from. As noted above, $DEST is /data/svnbackup. The parent of $DEST is /data. /data is a partition on the server. If that partition is gone, that's a failure that we're talking about recovering from. # Process each repository for REPO in `cat /tmp/SVNBackup.tmp` And again you're in trouble. If any of the repositories have whitespace in their names, or funky EOL characters, the individual words will be parsed as individual arguments. This is Linux. Anyone who creates a repository with white space in the name gets shot. do # some things are not repositories; ignore them if [ -d $SRCE/$REPO ] Here is a likely bug in the script. I treat every subdirectory of the SVNParent repository collection as
Re: My Backup Script
On 7/26/11 4:23 PM, Andreas Krey wrote: Because the commit came from my WC. My WC was up to date before the commit, and the only things that change have been in my WC already, so there is no possible way my WC can not be up to date. Except that it 'forgets' to update the WC revision info, and requires a separate update for that. It doesn't 'forget', it knows that doing it right would, in the general case, involve changing files in your working copy that you might not want to have changed. In what case? When svn lets me commit at all, it is when the WC is up to date; that is, there is nothing that needs to be merged into my WC. What files could need to be modified, under the assumption that the WC wasn't mixed-revision to begin with? In the typical case of concurrent work, someone else will have committed a different set of files before you. Your commit only pushes your changed files. Now your workspace and the repo head are very different. While in this case you may 'know' that no one else has made any changes in the repository, but it is probably a bad idea to get into habits that won't work when you are part of a team. I seriously don't know what you mean here. If an 'svn up' wouldn't change anything in my WC before I do a commit, an 'svn up' immediately after my commit (to the revision I committed) wouldn't do either, and there is no reason why that shouldn't be reflected in the WC by the commit instead requiring me to do a separate update. In the general case, you don't know that. Any number of other things may have happened in the repo before or after your commit. It is sort-of a special case when there have been no other changes and I suppose it wouldn't hurt anything in that case if subversion marked your WC as updated to the next rev, but then it would be very confusing when there were changes and it didn't. In any case, there is always the chance of someone beating me to the commit, so I need to update beforehand. But that can happen before the first commit just as well. And for most cases two consecutive commits just work; I did need some time to come up with the scenario. Consider changes to different files than the set you commit. Your commit won't have conflicts but you won't have (and may not want) the other changes yet. Btw, is there a way to undo an update that lead to merges with my changes (or even conflicts), and get back my original modified sandbox? If you accepted their changes in a conflict, probably not. But if you can figure out the revisions before/after the changes you want to back out you should be able to reverse-merge that change. -- Les Mikesell lesmikes...@gmail.com
Re: My Backup Script
On 7/26/11 5:14 PM, Andy Canfield wrote: I shy away from svnsync right now because it requires me to get TWO of these Subversion systems running. At present I am almost able to get one running. Almost. You don't need a 2nd server. Svnsync is a client to both repos, but the side it is writing can use file:/// access to avoid the need to have another server. Suppose we do a backup every night at midnight, copying it to a safe place. And suppose that the server dies at 8PM Tuesday evening. Then all submits that occurred on Tuesday have been lost. Presumably we'd find out about this on Wednesday. But a working copy is a valid working copy until you delete it. Assuming that the working copies still exist, all we need to do is * Restore the working SVNParent repository collection on a replacement computer. * Have everyone 'svn commit' from their working copies. * Unscramble the merge problems, which should be few. But you can't do this if the WC was updated past the rev of your restored repo. Or if you have a different uuid. -- Les Mikesell lesmikes...@gmail.com
Re: SVN 1.7 SVNParentPath broken
On Tue, 2011-07-26 at 11:13 +0200, Mario Brandt wrote: This is because the repository format changed slightly between the alpha releases and the beta2 release. You will need to re-create the repository. I had the exact same problem, dump and load into a new repository worked for me. The issues are not the repos. I can access my 1.6.17 and older repos without any issues. That was the case for me too - I had one repository which I created with alpha2, and load from a dump file. It worked fine with alpha3, and then I saw the error you have with beta2. At the same time, alpha2, alpha3, and beta2 all worked happily with my other repositories, which had been created by svn 1.6.x. I was not using SVNParentPath with these repositories, so can't comment on that, but definitely could not access my alpha2 created repository from beta2 using mod_dav_svn and apache. Tony The file system layout is /opt/repos --- ParentPath /opt/repos/repo1 /opt/repos/repo2 /opt/repos/repo3 /opt/repos/repoN As it was in SVN 1.6 SVNParentPath should show a list of the repos 1,2,3 to N [1] Second of all, don't you get the error documented in http://subversion.apache.org/docs/release-notes/1.7#revprop-packing in that case? Nope I don't get that error. This is might related to the mod_dav_svn. I'm not sure. But at leat I can say that over apache (I don't use svnserve) I never had an issue with the 1.6.x repos with the mod_dav_svn 1.7.x apache module. Cheers Mario [1] http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.httpd.basic -- Tony Butt t...@cea.com.au CEA Technologies
Re: SVN 1.7 SVNParentPath broken
Tony Butt wrote on Wed, Jul 27, 2011 at 10:47:39 +1000: could not access my alpha2 created repository from beta2 using mod_dav_svn and apache. That's expected. Did you get the error documented at http://subversion.apache.org/docs/release-notes/1.7#revprop-packing or some other error?
disable security hole in svn+ssh?
I was trying to get http, svn, and svn+ssh to work. HERE IT IS USING HTTP: *svn info http://athol/svn/subdoc Authentication realm: http://athol:80 Athol Subversion Repository Password for 'andy': Path: subdoc URL: http://athol/svn/subdoc Repository Root: http://athol/svn/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)* HERE IT IS USING SVN: *svn info svn://athol/subdoc Authentication realm: svn://athol:3690 Subversion svnserve Password for 'andy': Path: subdoc URL: svn://athol/subdoc Repository Root: svn://athol/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)* HERE IS THE PROBLEM USING SVN+SSH: *svn info svn+ssh://athol/data/svn/subdoc The authenticity of host 'athol (192.168.1.113)' can't be established. ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7. Are you sure you want to continue connecting (yes/no)? yes kids@athol's password: Path: subdoc URL: svn+ssh://athol/data/svn/subdoc Repository Root: svn+ssh://athol/data/svn/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) * What's 'worse' about it? Well, 'kids' is a valid user name on the server; 'kids' can ssh into the server. But 'kids' has no authorization to access any Subversion repository in any way. To me this means that svn+ssh is a GIGANTIC security hole. Consider these commands: *ssh k...@example.com rm -rf /data/svn/subdoc* They do nothing; user 'kids' has no right to see anything inside the /data/svn directory, which is owned by www-data and readable (and writable) only by that user. But consider these commands: *mkdir t cd t svn checkout svn+ssh://example.com/data/svn/subdoc svn delete * **svn commit* These will post a revision deleting everything in the repository. And this second set of commands relies only on 'kids' being able to log in to the server; they need not have any permission to do anything in Subversion! Is there any way to modify things on the server to disable the svn+ssh: protocol without disabling either standard ssh or the svn: protocol?
