AW: 1.7 compatibility issue
I can confirm that listing the repository works with --config-option servers:global:http-library=neon. As reported by Ivan he fixed this issue in r1151177. Thanks! Regards, Thomas Von: Mark Phippard [mailto:markp...@gmail.com] Gesendet: Dienstag, 26. Juli 2011 18:17 An: Becker, Thomas Cc: users@subversion.apache.org Betreff: Re: 1.7 compatibility issue On Tue, Jul 26, 2011 at 11:44 AM, Becker, Thomas thomas.bec...@torex.com wrote: 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/ 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. .
AW: My Backup Script
Hi, Andreas, Von: Andreas Krey [mailto:a.k...@gmx.de] 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. That assumption is wrong, I guess. As far as I know, commit hooks can modify the commit. (This behavior is discouraged, but nevertheless it is possible. 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
Re: SVN 1.7 SVNParentPath broken
On Tue, Jul 26, 2011 at 11:13:24AM +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. 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. Mario, Did you check what your Apache server logs say when the problem happens? You already quoted this error: Could not open the requested SVN filesystem. Is there any more information in the server logs that might shed some light on it? Without more information I would suppose that this is a problem in your setup until we get confirmation of this problem from someone else.
Re: disable security hole in svn+ssh?
On Wednesday 27 July 2011, Andy Canfield wrote: I was trying to get http, svn, and svn+ssh to work. Just one thing: Why? Why do you want more than one protocol? I could imagine read-only HTTP and read-write HTTPS, but that's the only reason for multiple access methods I could imagine. 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. Not true, they will create a new revision in the repository and that revision is empty. ;^) No need to check out for that either, you can pass URLs to svn delete. No data loss either, all earlier revisions are still present and unchanged. I agree that such a revision is disturbing though, but not a fatal data loss. Anyhow, if you are using svn+ssh, you are only tunnelling the svn network protocol through an SSH connection. This is achieved by starting an svnserve process through SSH. svnserve itself will use direct file access to the repository. So, if you can do that and you can simply log in with a shell using SSH, then your security hole is that users have direct access to the files that make up a repository using an SSH shell. If, as you claim, users don't have file access to the repo via SSH, then you have some privilege escalation in between, probably using SUID executables. Summary: There is no security hole in SVN that you didn't drill yourself, either using the wrong permissions on the repository or using SUID executables. 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! The permission [..] in Subversion only exists in the actually used server like Apache or svnserve (even though the svnserve configs are stored in the repo folder). With the file access method, you need file-level access to the repo anyway, so any permissions could only be considered a suggestion anyway. 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? Disable the file-level access to the repository for users, only allow access to servers. If you need encryption, you could restrict access to using HTTPS or restrict access via svn to connections from localhost. In the latter case, users would have to SSH into the machine and work there or, better, create a tunnel. 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. **
Sparse checkout error.
While trying to do a sparse checkout in TortoiseSvn (version TortoiseSVN 1.6.99, Build 21709 - 64 Bit , 2011/07/22 16:21:33) I got the following error message. Subversion Exception! io. Subversion encountered a serious problem. r Please take the time to report this on the Subversion mailing list (users@subversion.apache.org) with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.orgimailing-lists.html Subversion reported the following: In file 'D:\ Development\ SVN\TortoiseSVN\ ext\ subversion\ subversion\ libsvn_ wc wc_db.c* line 6617: assertion failed (svn_dirent_is_absolute(local_abspath)) OK ___ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
Web site: checkout or export?
We're doing a web site. The whole site will be under revision control using Subversion. So there are at least three of these: my working copy, the repository, and the working web site. How do I get a working web site? By export? or by checkout? + After we 'svn checkout', If we need to change something on the working web site, we can 'svn commit' to get the changes into the repository. Using 'svn export' we would have to make the changes on a working copy, then commit, then 'svn export' again. + After we 'svn checkout', whenever a new version is in the repository we can 'svn update' and get only the updated files. If we have to use 'svn export' it will give us ALL of the files. - Using 'svn checkout', the working web site will have the subversion control files in the .svn subdirectory, which might be a security hole. Advice?
Re: disable security hole in svn+ssh?
On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield andy.canfi...@pimco.mobi wrote: I was trying to get http, svn, and svn+ssh to work. Dude. Pick one. Getting all three to play nicely together is destablilizing. 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) Hold it right there. You're providing password based repository access via HTTP, not HTTPS? Please rethink this unless you *want* the passwords for this repository to be quite insecure and sniffable, especially if you're using normal user login passwords. Also note. For HTTP access from Linux and UNIX systems, the default behavior is to store the password, in cleartext, in $HOME/.subversioon/. *That* is a longstanding security issue that I've been ranting about for *years*. Subversion 1.6.x, very reasonably, now asks for permission before doing that, But if you're using the same password authenticatoin for svn+ssh://, http://, https://, and svn:// based access, you're now writing your password in plain text. locally. svn+ssh:// doesn't recored that plain text password, http:// and htps:// do. 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) Again. Unencrypted passwords, unless you're using something like SASL. Do not use this for normal user passwords. 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; Which it need not be. The gudebook does not make this clear enough: For users who have normal shell access *anyway*, many sites do use this approach and simply set the repository to be manged with group access to designated users. But in the we don't want people to need shell access to use svn+ssh, you need to set up something like an SSH key on a shared account with forced commands, typically with this kind of URL. svn+ssh://svn@sitename/svn/reponame/ That svn user can be set to have no valid shell, with its shell set to something like /sbin/nologin. This is actually quite common for system services to have no valid shell. This is how the apache or www-data user is usually set up. '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. See above. That forced command bit is really important for systems where you don't want subverson authorized users to have shell access. I've actually had extensive battles about this sort of thing with sites where the internal policy was as long as they're in, we already trust them with shell on such servers. This is actually tied to a subtler, longstanding deficit in Subversion: a dedicated shell for an svn user. I've attempted myself to integrate this sort of thing into the rssh toolkit used for rsync access. 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. Only if you're using the shared account access method to svn+ssh, where the URL includes the username or otherwise successfully forces access to have that username. If you're doing the unfortunately common approach of normal user accounts with shared group access to the Subversion repository, you can scrub the database clean. It's one of the reasons I *hate* that normal user account method. The same sort of thing occurs in CVS repositories: it allows a considerable amount of relocation and behind the scenes editing of Subversion repositories, and is one of the ways to flush oversized binaries, such as DVD images, that soomeone might accidentally
Re: Web site: checkout or export?
On Jul 27, 2011, at 06:46, Andy Canfield wrote: We're doing a web site. The whole site will be under revision control using Subversion. So there are at least three of these: my working copy, the repository, and the working web site. How do I get a working web site? By export? or by checkout? + After we 'svn checkout', If we need to change something on the working web site, we can 'svn commit' to get the changes into the repository. Using 'svn export' we would have to make the changes on a working copy, then commit, then 'svn export' again. + After we 'svn checkout', whenever a new version is in the repository we can 'svn update' and get only the updated files. If we have to use 'svn export' it will give us ALL of the files. - Using 'svn checkout', the working web site will have the subversion control files in the .svn subdirectory, which might be a security hole. Advice? The .svn directories needn't be a security hole; you can configure your web server to not serve their contents, or even not acknowledge their existence. In my httpd.conf I have: RedirectMatch 404 .*/\.svn(/|$) You should also look into SVN::Notify::Mirror: http://search.cpan.org/perldoc?SVN::Notify::Mirror
Re: Sparse checkout error.
On Wed, Jul 27, 2011 at 09:13:09AM +0100, Pierre Best wrote: While trying to do a sparse checkout in TortoiseSvn (version TortoiseSVN 1.6.99, Build 21709 - 64 Bit , 2011/07/22 16:21:33) I got the following error message. Hi Pierre, This looks like a bug in Subversion. Your bug report does not include enough information so that others can independently reproduce it. Can you describe in more detail what sparse checkout process triggered this? If you have time it would be great if you could create a local repository with tortoisesvn (Create Repository here), add some folders and then try to reproduce the problem (use a file:// URL to access the repository). Then let us know what the repository structure looks like, and in which way you checked things out. This way it will be easier for others to trigger the crash. Thanks! Subversion Exception! io. Subversion encountered a serious problem. r Please take the time to report this on the Subversion mailing list (users@subversion.apache.org) with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.orgimailing-lists.html Subversion reported the following: In file 'D:\ Development\ SVN\TortoiseSVN\ ext\ subversion\ subversion\ libsvn_ wc wc_db.c* line 6617: assertion failed (svn_dirent_is_absolute(local_abspath))
Re: Svnsync
On Wed, Jul 27, 2011 at 02:24:42PM +0200, Onno van der Straaten wrote: Hi all, I'm trying to synsync a repository. I have done this in the past but it seems I have forgotten how to do this. From my notes I understand that I need to initialize the svnsync on the target repository. So I ssh to the target machine that has the target repos and issue the following command svnsync init file:///path_to_my_repos/ svnsync: Try 'svnsync help' for more info svnsync: Not enough arguments provided svnsync init expects 2 URLs: usage: svnsync initialize DEST_URL SOURCE_URL You are missing either the DEST_URL or the SOURCE_URL.
AW: Web site: checkout or export?
Hi, Andy, Von: Andy Canfield [mailto:andy.canfi...@pimco.mobi] - Using 'svn checkout', the working web site will have the subversion control files in the .svn subdirectory, which might be a security hole. You could use some pattern based access control (Apache is very configurable in that respect) to prevent remote access to all pathes containing .svn in their url. And the security hole should be not that large, as the .svn directory usually does not contain any authentication information. Subversion 1.7 will further improve on that situation, you only have a single .svn directory then. And you can use the trick of directing the webserver to a subdir of your working copy, so the .svn directory is completely out of the web servers path. Mit freundlichen Grüßen Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Entwicklung Memminger Str. 151 | 87439 Kempten | 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 Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915
Re: Svnsync
Thanks, I got it. On Wed, Jul 27, 2011 at 2:31 PM, Stefan Sperling s...@elego.de wrote: On Wed, Jul 27, 2011 at 02:24:42PM +0200, Onno van der Straaten wrote: Hi all, I'm trying to synsync a repository. I have done this in the past but it seems I have forgotten how to do this. From my notes I understand that I need to initialize the svnsync on the target repository. So I ssh to the target machine that has the target repos and issue the following command svnsync init file:///path_to_my_repos/ svnsync: Try 'svnsync help' for more info svnsync: Not enough arguments provided svnsync init expects 2 URLs: usage: svnsync initialize DEST_URL SOURCE_URL You are missing either the DEST_URL or the SOURCE_URL.
svnsync
A local SVN expert tells me svnsync is all I need with regards to moving several (about 2 hundred) repositories from a Unix server to a Linux server even though there are mixed versions of SVN. Some are 1.5x others are 1.6.x (all are FSFS).and the destination server will have 1.6.17 svn installed ( Subversion Edge ) Is it possible it is as simple as say doing an SFTP of all the Unix Repositories to the Linux server then running svnsync on each repo ? any one done this successfully I am a bit of a skeptic when a task of this magnitude ids described as being too simple. WE are taking about several repos many well over 4GB -- 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: SVN 1.7 SVNParentPath broken
Hi Stefen, of cause you can have the error log information. But I doubt it helps more. http://pastebin.com/N2TKddyE --- log from the alpha http://pastebin.com/rvsq4hDM --- log from current beta As I told the module tries to open the parent path as a repo which it isn't. Cheers Mario Did you check what your Apache server logs say when the problem happens? You already quoted this error: Could not open the requested SVN filesystem. Is there any more information in the server logs that might shed some light on it? Without more information I would suppose that this is a problem in your setup until we get confirmation of this problem from someone else.
Re: svnsync
On Wed, Jul 27, 2011 at 10:12 AM, Phil Pinkerton pcpinker...@gmail.comwrote: A local SVN expert tells me svnsync is all I need with regards to moving several (about 2 hundred) repositories from a Unix server to a Linux server even though there are mixed versions of SVN. Some are 1.5x others are 1.6.x (all are FSFS).and the destination server will have 1.6.17 svn installed ( Subversion Edge ) Is it possible it is as simple as say doing an SFTP of all the Unix Repositories to the Linux server then running svnsync on each repo ? any one done this successfully I am a bit of a skeptic when a task of this magnitude ids described as being too simple. WE are taking about several repos many well over 4GB If the existing repositories are FSFS, you could actually just move the repositories to the new server and use them. IOW, just copy the repository folder to the new server. svnsync is a good option if you do not want any downtime, otherwise, I would use svnadmin dump/load over svnsync. It will run faster but you should have the repositories offline while doing it. Where as with svnsync you could still be using the old repository until the new one is ready. Do not forget to recreate your hook scripts in the new repositories if you are using any. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: SVN 1.7 SVNParentPath broken
On Wed, Jul 27, 2011 at 04:14:16PM +0200, Mario Brandt wrote: Hi Stefen, of cause you can have the error log information. But I doubt it helps more. http://pastebin.com/N2TKddyE --- log from the alpha http://pastebin.com/rvsq4hDM --- log from current beta As I told the module tries to open the parent path as a repo which it isn't. What happens if you switch your Location / to something like Location /svn?
Svn Searcher
Anyone have experience installing and using Svn Searcher ? http://svn-search.sourceforge.net/ I have a client that would like to do Repository Searches. -- 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: Svn Searcher
On Wed, Jul 27, 2011 at 8:48 PM, Phil Pinkerton pcpinker...@gmail.comwrote: Anyone have experience installing and using Svn Searcher ? http://svn-search.sourceforge.net/ I have a client that would like to do Repository Searches. Yes I have done that. -- 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. -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Re: Svn Searcher
What platform did you install it on (Linux, Unix, Windows ) ? Was it installed on the Server , Cliient both ? Any issues or concerns, is it working ? How well ? Easy to install and use ? Any external dependencies and or Apache issues ? What about Security ( affects svn ACL , LDAP ??) Any feedback would be appreciated. On Wed, Jul 27, 2011 at 11:20 AM, vishwajeet singh dextrou...@gmail.com wrote: On Wed, Jul 27, 2011 at 8:48 PM, Phil Pinkerton pcpinker...@gmail.com wrote: Anyone have experience installing and using Svn Searcher ? http://svn-search.sourceforge.net/ I have a client that would like to do Repository Searches. Yes I have done that. -- 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. -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet -- 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: Svn Searcher
On Wed, Jul 27, 2011 at 8:56 PM, Phil Pinkerton pcpinker...@gmail.comwrote: What platform did you install it on (Linux, Unix, Windows ) ? I did it on windows and linux Was it installed on the Server , Cliient both ? It's web based hence no install required on client side Any issues or concerns, is it working ? How well ? No issues as such it's great product, just that it's not being maintained from long time, support is scarce Easy to install and use ? It can get tricky as there are two parts one indexer and other is webapp Any external dependencies and or Apache issues ? You need tomcat What about Security ( affects svn ACL , LDAP ??) svn ACL works on linux but not on windows Any feedback would be appreciated. I hope that helps. On Wed, Jul 27, 2011 at 11:20 AM, vishwajeet singh dextrou...@gmail.com wrote: On Wed, Jul 27, 2011 at 8:48 PM, Phil Pinkerton pcpinker...@gmail.com wrote: Anyone have experience installing and using Svn Searcher ? http://svn-search.sourceforge.net/ I have a client that would like to do Repository Searches. Yes I have done that. -- 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. -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet -- 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. -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Re: svnsync
On Wed, Jul 27, 2011 at 10:12 AM, Phil Pinkerton pcpinker...@gmail.com wrote: A local SVN expert tells me svnsync is all I need with regards to moving several (about 2 hundred) repositories from a Unix server to a Linux server even though there are mixed versions of SVN. Some are 1.5x others are 1.6.x (all are FSFS).and the destination server will have 1.6.17 svn installed ( Subversion Edge ) It's an efficient and graceful way to move them, one where you can presynchronize the data ahead of time and update it. You can also review your layouts. and see if there are repositories to merge, split, or discard at this time. svnsync does not bring along the local hook and configuration files, but only the repository contents. You'ld have to transfer them separately, but this is often safer. Is it possible it is as simple as say doing an SFTP of all the Unix Repositories to the Linux server then running svnsync on each repo ? There are profound dangers of doing this. It's a database on the back end. If someone adds one commit that you missed, or you copied one file before it was completely written to the database, you've corrupted your replica. This is why people are so careful to lock their old repositories read-only, mirror the material carefully, and only when they're finished do they activate the mirror repository. This is also all built into WanDisco's commercial multi-hosting tools. any one done this successfully I am a bit of a skeptic when a task of this magnitude ids described as being too simple. WE are taking about several repos many well over 4GB Which, by modern standards, is quite modest. By the way: use rsync instead of sftp, in order to be able to restart things if interrupted. -- 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: My Backup Script
Markus Schaber wrote on Wed, Jul 27, 2011 at 09:37:38 +0200: Hi, Andreas, Von: Andreas Krey [mailto:a.k...@gmx.de] 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. That assumption is wrong, I guess. As far as I know, commit hooks can modify the commit. (This behavior is discouraged, but nevertheless it is possible. Modifying the txn handed to the hook is discouraged because it's not possible to communicate the changes to the client, so its working copy becomes inconsistent with the repository. It's trickier but possible to write a hook that inspects the provided txn, /recreates/ it (possibly with modifications), commits /that/, and then rejects the originally-provided txn. The client working copy is consistent and will remain consistent after an 'svn up' (which will merge cleanly or conflict, as usual). 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
Re: svnsync
Mark Phippard wrote on Wed, Jul 27, 2011 at 10:16:10 -0400: On Wed, Jul 27, 2011 at 10:12 AM, Phil Pinkerton pcpinker...@gmail.comwrote: A local SVN expert tells me svnsync is all I need with regards to moving several (about 2 hundred) repositories from a Unix server to a Linux server even though there are mixed versions of SVN. Some are 1.5x others are 1.6.x (all are FSFS).and the destination server will have 1.6.17 svn installed ( Subversion Edge ) Is it possible it is as simple as say doing an SFTP of all the Unix Repositories to the Linux server then running svnsync on each repo ? any one done this successfully I am a bit of a skeptic when a task of this magnitude ids described as being too simple. WE are taking about several repos many well over 4GB If the existing repositories are FSFS, you could actually just move the repositories to the new server and use them. IOW, just copy the repository folder to the new server. And make sure /not/ to copy rep-cache.db that way. SQLite doesn't promise that the resulting db will be valid or consistent.
Re: SVN 1.7 SVNParentPath broken
Hi Stefan, What happens if you switch your Location / to something like Location /svn? that did the trick. Than it works with SVNParentPath. I wonder why it doesn't work like before with just / in the location container. :-/ Mario
Re: SVN 1.7 SVNParentPath broken
On Wed, Jul 27, 2011 at 4:41 PM, Mario Brandt jbl...@gmail.com wrote: Hi Stefan, What happens if you switch your Location / to something like Location /svn? that did the trick. Than it works with SVNParentPath. I wonder why it doesn't work like before with just / in the location container. :-/ Mario Probably because you have a default site at / that takes precedence when Apache parses its config.
Re: SVN 1.7 SVNParentPath broken
Hi all, thanks for your help. Probably because you have a default site at / that takes precedence when Apache parses its config. Different to 1.6 with 1.7 I had to set the document root the same as SVNParentPath. Now it works again with Location / Cheers Mario
Re: svnsync
On Jul 27, 2011, at 14:44, Daniel Shahaf wrote: Mark Phippard wrote on Wed, Jul 27, 2011 at 10:16:10 -0400: If the existing repositories are FSFS, you could actually just move the repositories to the new server and use them. IOW, just copy the repository folder to the new server. And make sure /not/ to copy rep-cache.db that way. SQLite doesn't promise that the resulting db will be valid or consistent. In what way should one copy rep-cache.db, then?
Re: svnsync
Ryan Schmidt wrote on Wed, Jul 27, 2011 at 16:07:46 -0500: On Jul 27, 2011, at 14:44, Daniel Shahaf wrote: Mark Phippard wrote on Wed, Jul 27, 2011 at 10:16:10 -0400: If the existing repositories are FSFS, you could actually just move the repositories to the new server and use them. IOW, just copy the repository folder to the new server. And make sure /not/ to copy rep-cache.db that way. SQLite doesn't promise that the resulting db will be valid or consistent. In what way should one copy rep-cache.db, then? http://www.sqlite.org/backup.html svn_sqlite__hotcopy() sqlite3 old.db .dump | sqlite3 new.db (this creates the new.db from scratch, it needn't (shouldn't?) have the schema already filled in)
Re: SVN 1.7 SVNParentPath broken
On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote: 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? It was not that error, but some other. There was some mention of XML in the browser window. Sorry, I can't remeber more of it than that. I put it down to an upgrade incompatibility from alpha[2|3] to beta2, recreated the repo, and did not see the problem again. I can try to reproduce it using my alpha3 build if you like... -- Tony Butt t...@cea.com.au CEA Technologies
Re: SVN 1.7 SVNParentPath broken
Tony Butt wrote on Thu, Jul 28, 2011 at 09:53:35 +1000: On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote: 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? It was not that error, but some other. There was some mention of XML in the browser window. Sorry, I can't remeber more of it than that. I put it down to an upgrade incompatibility from alpha[2|3] to beta2, recreated the repo, and did not see the problem again. I can try to reproduce it using my alpha3 build if you like... If you have a beta1 or beta2 build, can you try: * Creating a repository using =1.6.x or =beta1 * Making sure you can access that repository * Either: rm -rf the repository, and recreate it using 1.7.0-alpha3 or: change '4' to '5' on the first line of $REPOS_DIR/db/format * Trying to access the repository, reporting what error you get Thanks! Daniel
Re: SVN 1.7 SVNParentPath broken
On Thu, 2011-07-28 at 03:11 +0300, Daniel Shahaf wrote: Tony Butt wrote on Thu, Jul 28, 2011 at 09:53:35 +1000: On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote: 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? It was not that error, but some other. There was some mention of XML in the browser window. Sorry, I can't remeber more of it than that. I put it down to an upgrade incompatibility from alpha[2|3] to beta2, recreated the repo, and did not see the problem again. I can try to reproduce it using my alpha3 build if you like... If you have a beta1 or beta2 build, can you try: * Creating a repository using =1.6.x or =beta1 Already have at least one of each * Making sure you can access that repository Can definitely do that, for both 1.6.17, and 1.7.0 beta2 * Either: rm -rf the repository, and recreate it using 1.7.0-alpha3 Recreated using alpha3 or: change '4' to '5' on the first line of $REPOS_DIR/db/format * Trying to access the repository, reporting what error you get Tried to access the repository using mod_dav_svn 1.7.0 beta2 Saw this in the browser: This XML file does not appear to have any style information associated with it. The document tree is shown below. D:errorC:error/m:human-readable errcode=160043 Could not open the requested SVN filesystem /m:human-readable/D:error I checked the ownership of the repository files, all owned by www-data Other repo's in the tree can be accessed normally (1.6.17 and 1.7.0 beta2) Thanks! Daniel -- Tony Butt t...@cea.com.au CEA Technologies
Re: SVN 1.7 SVNParentPath broken
On Thu, 2011-07-28 at 10:50 +1000, Tony Butt wrote: On Thu, 2011-07-28 at 03:11 +0300, Daniel Shahaf wrote: Tony Butt wrote on Thu, Jul 28, 2011 at 09:53:35 +1000: On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote: 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? It was not that error, but some other. There was some mention of XML in the browser window. Sorry, I can't remeber more of it than that. I put it down to an upgrade incompatibility from alpha[2|3] to beta2, recreated the repo, and did not see the problem again. I can try to reproduce it using my alpha3 build if you like... If you have a beta1 or beta2 build, can you try: * Creating a repository using =1.6.x or =beta1 Already have at least one of each * Making sure you can access that repository Can definitely do that, for both 1.6.17, and 1.7.0 beta2 * Either: rm -rf the repository, and recreate it using 1.7.0-alpha3 Recreated using alpha3 or: change '4' to '5' on the first line of $REPOS_DIR/db/format * Trying to access the repository, reporting what error you get Tried to access the repository using mod_dav_svn 1.7.0 beta2 Saw this in the browser: This XML file does not appear to have any style information associated with it. The document tree is shown below. D:errorC:error/m:human-readable errcode=160043 Could not open the requested SVN filesystem /m:human-readable/D:error I checked the apache logs, and found this: [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] (20014)Internal error: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not fetch resource information. [500, #0] [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not open the requested SVN filesystem [500, #160043] [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not open the requested SVN filesystem [500, #160043] I think this is what you were expecting. I checked the ownership of the repository files, all owned by www-data Other repo's in the tree can be accessed normally (1.6.17 and 1.7.0 beta2) Thanks! Daniel -- Tony Butt t...@cea.com.au CEA Technologies -- Tony Butt t...@cea.com.au CEA Technologies
Re: SVN 1.7 SVNParentPath broken
Tony Butt wrote on Thu, Jul 28, 2011 at 11:52:14 +1000: I checked the apache logs, and found this: [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] (20014)Internal error: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not fetch resource information. [500, #0] [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not open the requested SVN filesystem [500, #160043] [Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not open the requested SVN filesystem [500, #160043] I think this is what you were expecting. Yes, it is, thanks. (mod_dav_svn sometimes logs more information than it presents to the client.)
