htpasswd without apache
Hello all, I'm trying to make a local repository (protocol svn://, without apache) works with a password file with htpasswd entries. But my svn does not recognize the passwords added there. How can I configure svn to make it work? Thanks.
Betr.: htpasswd without apache
Ada Battousai adabattou...@gmail.com schreef op 18/02/2011 06:36:40: I'm trying to make a local repository (protocol svn://, without apache) works with a password file with htpasswd entries. But my svn does not recognize the passwords added there. How can I configure svn to make it work? That won't work. The htpasswd file is used by apache, not by SVN itself. If you want to use just svn:// (not svn+ssh://) I _think_ the only option is a plain text file containing usernames and passwords: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.users DISCLAIMER http://www.tvh.com/newen2/emaildisclaimer/default.html This message is delivered to all addressees subject to the conditions set forth in the attached disclaimer, which is an integral part of this message.
problem with mutated vowel in log-message-contents
i need a tip to solve my problem with log-messages in our subversion-repository. (see the mail-conversation with the tortoisesvn team below). there are message that contain mutated vowel and i need to find all them and correct them. f.e. i want to replace 'übergabe' by 'uebergabe' or if this is to difficult only by '_bergabe'. can anybode give me tips / commands to do that or probably there is an tool (because the problem was already solved for another user)? thanks for help -thomas Mails with TortoiseSvn-Team: Hello i have an really *big problem *using tortoise-svn. The same problem has - by the way - eclipse-subversive with javahl-connector, but not with svnkit-connector. if i try to show the logs of ein entry/file/.. in tortoisesvn where the log-messages contain a mutated vowel (german: deutscher umlaut) then it brings an failure msg: and then it shows instead of the messages. can anybody help? Thomas log messages must be in utf8 encoding. That's a requirement of the svn library. If they're not, then anything can happen. For example if you access the repository with http(s), then those messages have to be sent in an xml response, and non-utf8 strings result in invalid xml. When you commit with TSVN, TSVN ensures the encoding. But it might be that other svn clients have a bug and don't properly encode the log messages. In that case you have to fix the repository on the server directly using the command line tools (svnadmin). Stefan we already want to correct the log-messages, but we did not find an way to get all the log messages with failures and then to correct them. is there a known way - a tip to help us? thanks thomas You have to ask for help with this on the Subversion users list. This is an issue with the server/repository, not with TSVN and you'll get much more help about this over there. Stefan Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications.
Re: problem with mutated vowel in log-message-contents
unix shell scripting could solved it for you bash for rev in $(svn log ... | sed -n -e ...); do svn ps --revprop svn:log $(svn pg svn:log -r $rev | sed -e s/oldstring/newstring/g;) ... ; done I leave the ...'s as an exercise to tgeur reader - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Feb 2011 13:16, Thomas STEININGER tsteinin...@racon-linz.at wrote: i need a tip to solve my problem with log-messages in our subversion-repository. (see the mail-conversation with the tortoisesvn team below). there are message that contain mutated vowel and i need to find all them and correct them. f.e. i want to replace 'übergabe' by 'uebergabe' or if this is to difficult only by '_bergabe'. can anybode give me tips / commands to do that or probably there is an tool (because the problem was already solved for another user)? thanks for help -thomas Mails with TortoiseSvn-Team: Hello i have an really *big problem *using tortoise-svn. The same problem has - by the way - eclipse-subversive with javahl-connector, but not with svnkit-connector. if i try to show the logs of ein entry/file/.. in tortoisesvn where the log-messages contain a mutated vowel (german: deutscher umlaut) then it brings an failure msg: and then it shows instead of the messages. can anybody help? Thomas log messages must be in utf8 encoding. That's a requirement of the svn library. If they're not, then anything can happen. For example if you access the repository with http(s), then those messages have to be sent in an xml response, and non-utf8 strings result in invalid xml. When you commit with TSVN, TSVN ensures the encoding. But it might be that other svn clients have a bug and don't properly encode the log messages. In that case you have to fix the repository on the server directly using the command line tools (svnadmin). Stefan we already want to correct the log-messages, but we did not find an way to get all the log messages with failures and then to correct them. is there a known way - a tip to help us? thanks thomas You have to ask for help with this on the Subversion users list. This is an issue with the server/repository, not with TSVN and you'll get much more help about this over there. Stefan Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications.
Re: problem with mutated vowel in log-message-contents
Guten Tag Thomas STEININGER, am Freitag, 18. Februar 2011 um 13:53 schrieben Sie: i need a tip to solve my problem with log-messages in our subversion-repository. (see the mail-conversation with the tortoisesvn team below). there are message that contain mutated vowel and i need to find all them and correct them. f.e. i want to replace 'übergabe' by 'uebergabe' or if this is to difficult only by '_bergabe'. can anybode give me tips / commands to do that or probably there is an tool (because the problem was already solved for another user)? First of all you should examine how this could happen and what exactly is present in the log messages in your repositories, you should make sure that the log messages contain the wrong bytes for ü etc. German umlauts are not a problem, normally. Before repairing your repository I would make sure that it's really damaged. You should attach the errors you got from TortoiseSVN as well. 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
SVN Structure/advantages
Hello, I was working with some projects web that had this struture: follows below. - All projects was in three branches. One branch for bugs, one branch for improvement and one branch for deploy . *So, I migrate each folder of project to a new project and began to use a TRUNK and tags as recommended at svn book.* Formerly, at my deploy tool, I was *only* using a branch for deploy; Now I use a tag for each project to deploy. At work, I had to do* **just* one switch for all projects. Now I have to do a switch for each project to work. (the projects has dependence). I am new at SVN, and a have a question about it: 1) What the advantages of to use the best practices (trunk and tags) as recommendded at svn book, if my work is more hard? Thank you and best regards, Fernando Freitas
RE: Betr.: htpasswd without apache
Ada Battousai adabattou...@gmail.com schreef op 18/02/2011 06:36:40: I'm trying to make a local repository (protocol svn://, without apache) works with a password file with htpasswd entries. But my svn does not recognize the passwords added there. How can I configure svn to make it work? That won't work. The htpasswd file is used by apache, not by SVN itself. If you want to use just svn:// (not svn+ssh://) I _think_ the only option is a plain text file containing usernames and passwords: http://svnbook.red- bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig .svnserve.auth.users I'm pretty sure you can use LDAP with svnserve via the SASL support. BOb
RE: SVN Structure/advantages
Hello, I was working with some projects web that had this struture: follows below. - All projects was in three branches. One branch for bugs, one branch for improvement and one branch for deploy . So, I migrate each folder of project to a new project and began to use a TRUNK and tags as recommended at svn book. Formerly, at my deploy tool, I was only using a branch for deploy; Now I use a tag for each project to deploy. At work, I had to do just one switch for all projects. Now I have to do a switch for each project to work. (the projects has dependence). I am new at SVN, and a have a question about it: 1) What the advantages of to use the best practices (trunk and tags) as recommendded at svn book, if my work is more hard? trunk/branches/tags is just a recommended way to organize your repository, it is by no means required. We use it for some projects and not for others. There is nothing wrong with your promotion type layout if that is what works best for you. I think the main advantage to the recommended layout comes with open source projects that use svn... since everyone will understand that layout and will have a very good idea what is what. but even with trunk / branches / tag... there is no specification of what is on trunk. Is that where stable/tested code is. Or is that where WIP code is? BOb
RE: migrate svn 1.4 to 1.6
I am planning a migrate/upgrade SVN server that work at windows 2003 server . My current version is 1.4 and I want to migrate to 1.6 1) Should I restart the windows server at the end of the process ? Is it needed? As already mentioned, not the server but you will need to restart apache / avnserve. I would shut them down before hand to make sure that you can upgrade all the files svn files properly (this is windoze after all). If your server never gets rebooted, now might be as good a time as any! 2) Do anybody have the step by step of a same experience? http://stackoverflow.com/questions/1160761/how-to-upgrade-svn-1-4- 4-r251 88-to-svn-1-6 ...is the best out of the first page of search results. Remember that upgrading the server is only part of the picture. Any new repos you create will get all the benefits but existing repos will not get the full benefits unless you can find the time to do a dump/load. Not 100% true, you can run svnadmin upgrade on your repositories also. It takes much less time. A dump load of our primary repo takes about a day. svnadmin upgrade (from 1.5 to 1.6 ran in about 10 mins on our repo.) BOb You don't have to do this but I would think about it... Remember the clients too.
Re: migrate svn 1.4 to 1.6
I am planning a migrate/upgrade SVN server that work at windows 2003 server . My current version is 1.4 and I want to migrate to 1.6 1) Should I restart the windows server at the end of the process ? Is it needed? As already mentioned, not the server but you will need to restart apache / avnserve. I would shut them down before hand to make sure that you can upgrade all the files svn files properly (this is windoze after all). If your server never gets rebooted, now might be as good a time as any! 2) Do anybody have the step by step of a same experience? http://stackoverflow.com/questions/1160761/how-to-upgrade-svn-1-4- 4-r251 88-to-svn-1-6 ...is the best out of the first page of search results. Remember that upgrading the server is only part of the picture. Any new repos you create will get all the benefits but existing repos will not get the full benefits unless you can find the time to do a dump/load. Not 100% true, you can run svnadmin upgrade on your repositories also. It takes much less time. A dump load of our primary repo takes about a day. svnadmin upgrade (from 1.5 to 1.6 ran in about 10 mins on our repo.) BOb Also make sure to upgrade all the svn client applications to 1.6 after upgrading your svn server and the repository to 1.6. There were issues with non recursive checkouts using some svn client applications. Ankush You don't have to do this but I would think about it... Remember the clients too.
Re: migrate svn 1.4 to 1.6
On Fri, Feb 18, 2011 at 08:34:41AM -0800, ankush chadha wrote: Also make sure to upgrade all the svn client applications to 1.6 after upgrading your svn server and the repository to 1.6. There were issues with non recursive checkouts using some svn client applications. Which issues in particular? Can you point to relevant mailing list threads or issue numbers? Because how can people tell whether the issue might affect them if they can't get more specific information about the problem? How can they tell whether the problem might be serious or benign for their use cases? In general, any compatibility issues between clients and servers of different versions can be found in the compatibility tables in the release notes. For 1.5 and 1.6 this would be: http://subversion.apache.org/docs/release-notes/1.5.html#new-feature-compatibility-table http://subversion.apache.org/docs/release-notes/1.6.html#new-feature-compatibility-table If the issue you're referring to isn't listed there, it would help if you could point at more specific information. (I'm also interested because I'd like to know about the issue -- I cannot recall it off the top of my head.) Thanks!
Re: internal dirs showing up on update
On Thu, Feb 17, 2011 at 8:56 PM, Blair Zajac bl...@orcaware.com wrote: On 2/17/11 12:50 PM, Bob Archer wrote: I have so SVN repos (subversion) and I use them with no proble. But when we do updates/commints on client (tortoise) we always get teh internal directories: conf dav db hooks locks format README.txt These es are internal and should not appear right? How do I remove this? I assume these folder are in your repository. Just go into the repository browser in TortoiseSVn and delete the folders. It sounds like somebody checked in a copy of a repo into the repo, in which case it's safe to delete. Blair Ok! Thank you all for the support. As suggested I just deleted it and committed them and its working properly. Still I found it odd that some random user would put them there when they don't actually know what folders are in the server. Plus it happened in at least 2 repos. I suspect some random client bug :S Any way, thanks a lot for the help NC
Re: internal dirs showing up on update
Nuno Carapeto carap...@gmail.com wrote on 02/18/2011 12:19:39 PM: On Thu, Feb 17, 2011 at 8:56 PM, Blair Zajac bl...@orcaware.com wrote: On 2/17/11 12:50 PM, Bob Archer wrote: I have so SVN repos (subversion) and I use them with no proble. But when we do updates/commints on client (tortoise) we always get teh internal directories: conf dav db hooks locks format README.txt These es are internal and should not appear right? How do I remove this? I assume these folder are in your repository. Just go into the repository browser in TortoiseSVn and delete the folders. It sounds like somebody checked in a copy of a repo into the repo, in which case it's safe to delete. Blair Ok! Thank you all for the support. As suggested I just deleted it and committed them and its working properly. Still I found it odd that some random user would put them there when they don't actually know what folders are in the server. Plus it happened in at least 2 repos. I suspect some random client bug :S We have found a number of users do this with TortoiseSVN. They appear to be doing a Create repository here, followed by an Import... to the URL they were given, then finally understand what they really wanted to do was a SVN Checkout... Checkout seems to be a foreign concept (and apparently scary one) to some new non-technical users and they seem to struggle their way through a number of other more inviting steps before they find the right one. I've contemplated suggesting to the TortoiseSVN developers that they should add a warning if an user tries to do an Import... with a directory that contains an fsfs repository structure. Kevin R.
Re: internal dirs showing up on update
On Fri, Feb 18, 2011 at 13:19, Nuno Carapeto carap...@gmail.com wrote: On Thu, Feb 17, 2011 at 8:56 PM, Blair Zajac bl...@orcaware.com wrote: On 2/17/11 12:50 PM, Bob Archer wrote: I have so SVN repos (subversion) and I use them with no proble. But when we do updates/commints on client (tortoise) we always get teh internal directories: conf dav db hooks locks format README.txt These es are internal and should not appear right? How do I remove this? I assume these folder are in your repository. Just go into the repository browser in TortoiseSVn and delete the folders. It sounds like somebody checked in a copy of a repo into the repo, in which case it's safe to delete. Blair Ok! Thank you all for the support. As suggested I just deleted it and committed them and its working properly. Still I found it odd that some random user would put them there when they don't actually know what folders are in the server. Plus it happened in at least 2 repos. I suspect some random client bug :S Any way, thanks a lot for the help Not that surprising, actually. I've had a number of users who, early in their use of Subversion, would create a repository when they meant to create a working copy (checkout). It's very possible that someone did this, then realized their error, did a checkout to the same directory, then committed everything.
Re: migrate svn 1.4 to 1.6
Also make sure to upgrade all the svn client applications to 1.6 after upgrading your svn server and the repository to 1.6. There were issues with non recursive checkouts using some svn client applications. Which issues in particular? Can you point to relevant mailing list threads or issue numbers? Because how can people tell whether the issue might affect them if they can't get more specific information about the problem? How can they tell whether the problem might be serious or benign for their use cases? In general, any compatibility issues between clients and servers of different versions can be found in the compatibility tables in the release notes. For 1.5 and 1.6 this would be: http://subversion.apache.org/docs/release-notes/1.5.html#new-feature-compatibility-table http://subversion.apache.org/docs/release-notes/1.6.html#new-feature-compatibility-table If the issue you're referring to isn't listed there, it would help if you could point at more specific information. (I'm also interested because I'd like to know about the issue -- I cannot recall it off the top of my head.) Thanks! Hi Stefan This is what I posted more than an year back. I was mainly facing two issues when I was using svnant that internally uses svnkit. http://readlist.com/lists/subversion.tigris.org/users/10/52332.html http://article.gmane.org/gmane.comp.version-control.subversion.subclipse.user/15584/match= Performance issue I was able to resolve by upgrading svnkit that was shipped with svnant. I added bunch of additional svnkit dependencies to the classpath (jna) and set one of the parameters to false (set svnkit.symlinks=false ) I was able to workaround the second issue by not performing non recursive svn checkouts using svnant. Ankush
RE: internal dirs showing up on update
On Fri, Feb 18, 2011 at 13:19, Nuno Carapeto carap...@gmail.com wrote: On Thu, Feb 17, 2011 at 8:56 PM, Blair Zajac bl...@orcaware.com wrote: On 2/17/11 12:50 PM, Bob Archer wrote: I have so SVN repos (subversion) and I use them with no proble. But when we do updates/commints on client (tortoise) we always get teh internal directories: conf dav db hooks locks format README.txt These es are internal and should not appear right? How do I remove this? I assume these folder are in your repository. Just go into the repository browser in TortoiseSVn and delete the folders. It sounds like somebody checked in a copy of a repo into the repo, in which case it's safe to delete. Blair Ok! Thank you all for the support. As suggested I just deleted it and committed them and its working properly. Still I found it odd that some random user would put them there when they don't actually know what folders are in the server. Plus it happened in at least 2 repos. I suspect some random client bug :S Any way, thanks a lot for the help Not that surprising, actually. I've had a number of users who, early in their use of Subversion, would create a repository when they meant to create a working copy (checkout). It's very possible that someone did this, then realized their error, did a checkout to the same directory, then committed everything. Agreed... I very much doubt there is a client bug... more like a user bug. BOb
Re: Subversion Permissions Question.
Thank you very much for your help. - Monica On Feb 13, 2011, at 9:04 AM, Thorsten Schöning tschoen...@am-soft.de wrote: Guten Tag MonicaS, am Freitag, 11. Februar 2011 um 22:55 schrieben Sie: If I check with tortoiseSVN or with SVN list to Eng-Tech I get the following: ABC-SDKs J-SDKs I would think that this means that those directories are folders within the repo Eng-Tech, regardless of your file system structure, because svn list etc. doesn't combine file system level directories and repo level directories in their output. But they should have if those to folders where the repos beneath Eng-Tech in your file system. If I check with tortoiseSVN or with SVN list to ABC-SDK I get the following: A-SDKs B-SDKs C-SDKs This should be really the content of the repository itself. This means that A thru C SDKs folder belong to the repository ABC-SDKs and J-SDKs belongs to the J-SDKs repository; and Eng-Tech is empty. Maybe I'm wrong but I think Eng-Tech is not empty, but consists the folders you wrote first. Maybe Eng-Tech does have content, like the other repos unter Eng-Tech in the file system, but thos directories aren't used for some reason? Maybe your repos started that way, something didn't work as expected and things have changed? Are you able to rename the repos beneath Eng-Tech in your file system? That way nobody coudl use them anymore and you were really sure what is in the repo Eng-Tech and what is not. If you rename name ABC-SDKs to ABC-SDKs_ for some seconds, your svn list of Eng-Tech should refelct those renamings or it's clear that Eng-Tech does have content, the versioned directories ABC-SDKS and J-SDKs. This is why I'm or was confused. I wanted to understand why we have so many repositories. I noticed that some of the repositories are hard links to other file-systems. Maybe this was done because of the disk space... I don't know. In any case, your repo structure is not supported and you should change it after fully understanding it and possible. 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
bug Subversion 1.6.15 saslpasswd2.exe does not work
saslpasswd2.exe included with Subversion 1.6.15 does not generate a sasldb nor does a previously generated sasldb work with the svnserve.exe service running. I reverted to 1.6.13-r10002845 and saslpasswd2.exe was able to sucessfully generate sasldb and previously generated sasldb worked with svnserve.exe service. saslpasswd2.exe -v on both version state Built against SASL API version 2.1.23 LibSasl version 2.1.23 by Cyrus SASL regards, Coleman
