Re: Mixed authentication and WebSVN on same host
2011/6/9 Pier-Luc Petitclerc : > The problem I have with that is related to the user authentication. I have > read that mixed authentication (anonymous vs "registered") is possible with > authz and that's what I tried implementing. Read The Book [1], as well as HTTPD manuals. [2] 1) To mix anonymous and non-anonymous auth (i.e. allow read-only svn access for anons) you configure different access rules for different HTTP methods. I.e. GET etc. will go without authentication, but REPORT, PUT, ... will require authentication. [1] has an example. 2) "Satisfy Any" is wrong. You should be careful with it. (If you have Allow/Deny statements elsewhere it will be enough to satisfy auth requirements). See [2] and you'd better configure "Satisfy All". [1]: http://svnbook.red-bean.com/ [2]: http://httpd.apache.org/docs/ > > However, the problem I'm having now is that Apache does not ask users for > credentials presumably due to the "Satisfy Any" statement. Unless I am > mistaken, that is how Authz work - to grab usernames off Apache's > authentication and associate it with the ACL specified in > AuthzSVNAccessFile... well, that's not working. I've tried many combinations > to no avail... so is there someone who has configured something similar? > You can configure an access log and look there for what requests and responses are. When apache requests auth it is HTTP response code 401. Best regards, Konstantin Kolinko
Unretrievable file
Hello, I have a problem that began when I mistakenly attempted to switch a file to an older tagged version. It instead converted my file into a folder containing the whole of the older tagged project. I tried to switch back but it would say “can’t replace a folder from within”. I was advised to delete it and then update my working copy in order to restore my file and SVN back to a happy state. However this didn’t work. The situation now is that if I attempt almost any operation in the directory that contained the myOriginalFile, it tells me “the . . path (i.e. the directory ) is locked, use Cleanup”. But if I try to use Cleanup it says “error processing entry for myOriginalFile.c, myOriginalFile.c is already under version control”. What can I do to get back to normality? I’m prepared to throw away the original file and start again with a new name but I just can’t seem to make SVN forget about it? Please help. Bill Herring YellowbrickTracking/Rock 7 Mobile.
Svn mergeinfo appearing on sub-directories
Further information on this... it's definitely not related to the authz as the same behaviour happens when using the file: protocol. It appears to be to do with the mergeinfo that's already present, as if I delete it all then it works as expected. When doing a merge, is the mergeinfo anywhere other than the source and target trees taken into account somehow? Failing all else my next step will be to attempt to debug with svnkit, as I don't know C very well. Cheers, jamie Morning, Recently, when any user merges up from trunk to their topic branch, svn appears to do it directory by directory for immediate sub-directories of the branch root, so each sub-directory gets explicit mergeinfo. [X:\XYZ.11650]svn merge http://svn.example.net/ABCD/Source/trunk --- Merging r38851 through r39538 into 'Automation': UAutomation\TestingDashboard\TestingDashboard.sln ... --- Merging r38851 through r39541 into 'Tools': ... Up to around 6 months ago this would not have been noticed, however we have had so many problems with mergeinfo that there is now a hook that prevents mergeinfo going anywhere other than the "branch" roots. The hook is working fine, the problem is that svn is doing this, when there seems to be no apparent reason. I understand that this would happen if the user did not have read access to one of the sub-directories in the source tree, but this is not the case. I have compared a svn ls -R using the file protocol with the same using the http protocol, just to be sure, and there is no difference. It could also happen if the target wc was not at infinite depth, but that's not the case either, nor switched sub-dirs, or anything similar. There is no sub-tree mergeinfo on the trunk. What other problem could be causing this? Cheers, jamie === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
Re: Svn mergeinfo appearing on sub-directories
On Thu, Jun 9, 2011 at 1:18 PM, Echlin, Jamie wrote: > Further information on this... it's definitely not related to the authz > as the same behaviour happens when using the file: protocol. It appears > to be to do with the mergeinfo that's already present, as if I delete it > all then it works as expected. > > When doing a merge, is the mergeinfo anywhere other than the source and > target trees taken into account somehow? > > Failing all else my next step will be to attempt to debug with svnkit, > as I don't know C very well. > > Cheers, jamie > > Morning, > > Recently, when any user merges up from trunk to their topic branch, svn > appears to do it directory by directory for immediate sub-directories of > the branch root, so each sub-directory gets explicit mergeinfo. > > [X:\XYZ.11650]svn merge http://svn.example.net/ABCD/Source/trunk > --- Merging r38851 through r39538 into 'Automation': > U Automation\TestingDashboard\TestingDashboard.sln > ... > --- Merging r38851 through r39541 into 'Tools': > ... > > Up to around 6 months ago this would not have been noticed, however we > have had so many problems with mergeinfo that there is now a hook that > prevents mergeinfo going anywhere other than the "branch" roots. The > hook is working fine, the problem is that svn is doing this, when there > seems to be no apparent reason. > > I understand that this would happen if the user did not have read access > to one of the sub-directories in the source tree, but this is not the > case. I have compared a svn ls -R using the file protocol with the same > using the http protocol, just to be sure, and there is no difference. > > It could also happen if the target wc was not at infinite depth, but > that's not the case either, nor switched sub-dirs, or anything similar. > > There is no sub-tree mergeinfo on the trunk. > > What other problem could be causing this? Hi Jamie, This is normal behavior of svn currently. Every subtree that already has "explicit mergeinfo" (meaning it has its own svn:mergeinfo property) will have that mergeinfo updated on every subsequent merge. That is done because it needs to be kept up to date. If a node doesn't have mergeinfo of its own, it inherits it from its parent directory. But from the moment it has explicit mergeinfo of its own, it no longer inherits anything, and so the property needs to be kept up to date all the time. Even if that subtree is totally not affected by the merge. See [1] for more in-depth info. I know this can be confusing/annoying. The upcoming 1.7 release should normally improve this situation, because it will only update the mergeinfo on those subtrees that are affected by the merge. HTH, -- Johan [1] http://www.collab.net/community/subversion/articles/merge-info.html (a huge article, but it contains a lot of useful information if you want to understand how mergeinfo works)
RE: Svn mergeinfo appearing on sub-directories
Hi Johan, > This is normal behavior of svn currently. Every subtree that > already has "explicit mergeinfo" (meaning it has its own svn:mergeinfo > property) will have that mergeinfo updated on every subsequent merge. > That is done because it needs to be kept up to date. Thanks for your response. BTW, http://www.collab.net/community/subversion/articles/merge-info.html is my mergeinfo bible, I have literally pored over every word, in excruciating detail. The issue is that neither the source nor the target branches have mergeinfo on the sub-directories already, this merge introduces it. And this issue has only started happening in the last few weeks. > If a node doesn't have mergeinfo of its own, it inherits it from its parent directory. But not always... Under what circumstances does a sub-tree start to get explicit mergeinfo? As I said, I know a few cases where it happens and is required, but these don't seem to apply. Cheers, jamie === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
attaching a hook to svn commit to generate TRAC-wiki page
Dear SVN experts, I'm new to SVN and I would like to ask if there is a tutorial how to setup post-commit hooks in SVN. What I'd like to implement is the following behavior: - Whenever a new app is submitted (added to SVN), a new TRAC-WIKI page is generated automatically. - Whenever an existing app is updated, the corresponding TRAC-WIKI page is updated. - Whenever an existing app is deleted from SVN, the corresponding TRAC-wiki page is deleted. The information for the WIKI page are included in the app Readme file. The script that is supposed to be triggered with an SVN commit will decide what to do based on what it finds in the repo and in TRAC. (Quick background: We're a group of researchers writing a lot of benchmarks. Benchmarks are maintained in an SVN repo on the same system where Apache and TRAC are running. TRAC is running in a default configuration and works fine.) I'd be happy about any hint on how to implement this / on any best-practices. Thanks a lot. Jan.
Re: Svn mergeinfo appearing on sub-directories
On Thu, Jun 09, 2011 at 01:42:33PM +0100, Echlin, Jamie wrote: > Hi Johan, > > > This is normal behavior of svn currently. Every subtree that > > already has "explicit mergeinfo" (meaning it has its own svn:mergeinfo > > property) will have that mergeinfo updated on every subsequent merge. > > That is done because it needs to be kept up to date. > > Thanks for your response. > > BTW, http://www.collab.net/community/subversion/articles/merge-info.html > is my mergeinfo bible, I have literally pored over every word, in > excruciating detail. > > The issue is that neither the source nor the target branches have > mergeinfo on the sub-directories already, this merge introduces it. And > this issue has only started happening in the last few weeks. > > > If a node doesn't have mergeinfo of its own, it inherits it from its > parent directory. > > But not always... Under what circumstances does a sub-tree start to get > explicit mergeinfo? As I said, I know a few cases where it happens and > is required, but these don't seem to apply. Hmmm... Does the parent of the offending directory have non-inheritable mergeinfo? (Mergeinfo entries that have an asterisk appended are not inheritable.)
problem installing subversion without berkeley DB
Hi, I'm trying to install subversion 1.6.15 without bekerley DB (which is not installed). I have launch the command ./configure -without-berkeley-db but when doing make install the following error occurs: grep: can't open /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la Can't open /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la libtool: link: `/usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la' is not a valid libtool archive make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1 How could I resolve this error ? Regards Pierrick ORBAN Support Team Infogérance Steria 05.62.19.83.35 dcs_ext_...@astrium.eads.net Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Astrium decline toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique. This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified. - Astrium SAS (393 341 516 RCS Paris) - Siege social: 6 rue Laurent Pichat, 75016 Paris, France
possible mechanism of repo corruption
I just suffered a fairly major repo corruption problem. Fortunately I had nightly dumps to restore from as well as an updated working copy of the affected repos, so the only thing I lost was some file history. Now I'm trying to figure out what caused the issue and if I can prevent it in the future. I have two areas of concern: 1. The repos are stored on our RAID and accessed over NFS mounted with the nolock option. I've read that this isn't a concern with the fsfs backend, but I'm still worried this had something to do with it. 2. We access the repos over both dav_svn and ssh spawning svnserve (using the wrapper script to set umask to 002). I auth apache through pam, so uid/gid is identical for both methods for all users. These repos were stable for a solid year with no problems using only dav_svn. I only introduced svnserve recently to make accessing the repos from outside the firewall easier with tortiseSVN and one month laterbroken repos. Is any of this considered bad practice that could lead to repo corruption? thanks, Matt
RE: Svn mergeinfo appearing on sub-directories
> Hmmm... > Does the parent of the offending directory have > non-inheritable mergeinfo? > (Mergeinfo entries that have an asterisk appended are not > inheritable.) Hi Stefan... Before the merge only the source (/trunk) and target (branches/topic-XYZ) have mergeinfo, not parents or sub-directories of either. The source and target both have two rev ranges for a single branch with an asterisk, but this is for a completely unrelated branch... Cheers, jamie === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
Strange merge behaviour
Hi, I'm facing a problem where I get items modified by a merge although there should be nothing to merge at all. I create a new branch from trunk. I checkout from that new branch. I merge from trunk into the new branch. [ No intermediate commit did happen as I'm doing this on a personal backup copy of the repository. ] svn status now shows some modified elements, and if I look at them with svn diff, I get something like Property changes on: path/to/file ___ Modified: svn:mergeinfo Merged /project/trunk/path/to/file:r1234 Why is this and how can I get rid of this strange behaviour? Thanks... Dirk -- Dirk Heinrichs | Tel: +49 (0)211 56623 316 Configuration Manager | Fax: +49 (0)211 56623 450 Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com Wanheimerstraße 68 | Web: http://www.de.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. signature.asc Description: signature.asc
Re: possible mechanism of repo corruption
On Thu, Jun 09, 2011 at 09:48:18AM -0400, Matthew Beals wrote: > I just suffered a fairly major repo corruption problem. Fortunately I had > nightly dumps to restore from as well as an updated working copy of the > affected repos, so the only thing I lost was some file history. Now I'm > trying to figure out what caused the issue and if I can prevent it in the > future. > > I have two areas of concern: > > 1. The repos are stored on our RAID and accessed over NFS mounted with the > nolock option. I've read that this isn't a concern with the fsfs backend, > but I'm still worried this had something to do with it. > > 2. We access the repos over both dav_svn and ssh spawning svnserve (using > the wrapper script to set umask to 002). I auth apache through pam, so > uid/gid is identical for both methods for all users. These repos were > stable for a solid year with no problems using only dav_svn. I only > introduced svnserve recently to make accessing the repos from outside the > firewall easier with tortiseSVN and one month laterbroken repos. > > Is any of this considered bad practice that could lead to repo corruption? FSFS requires file locking to ensure consistency when multiple processes concurrently access the repository. If the repository is accessed over NFS without locking corruption could certainly occur. I'm not sure where you could have gotten the opposite information from. Did you read this in Subversion's documentation or somewhere else? If your Apache server is handling requests via threads (rather than forking processes) this might explain why you never saw this problem with just dav. The threads can synchronise via mutexes which live in the same process address space. But separate processes require file locking for proper synchronisation.
RE: Strange merge behaviour
Context: -Original Message- From: Heinrichs, Dirk [mailto:dirk.heinri...@capgemini.com] ... svn status now shows some modified elements, and if I look at them with svn diff, I get something like Property changes on: path/to/file ___ Modified: svn:mergeinfo Merged /project/trunk/path/to/file:r1234 Why is this and how can I get rid of this strange behaviour? Comments: Each and every event in a project get a revision number, and a merge is definitely an event that gets recorded by SVN. SVN tries to be omniscient within a project so even if the code isn't changing in a merge event, the increment in revision number and the reason behind the increment still needs to get recorded. I don't think you'll be able to get rid of that behavior unless you change your strategy for making personal backups. Best, -Tim
AW: possible mechanism of repo corruption
Hi, > Von: Stefan Sperling [mailto:s...@elego.de] > If your Apache server is handling requests via threads (rather than > forking > processes) this might explain why you never saw this problem with just > dav. > The threads can synchronise via mutexes which live in the same process > address space. But separate processes require file locking for proper > synchronisation. If there's only one machine running the Apache server, and the svnserve is on a different one, then another hint may be that the apache machine locked the files locally but not on the NFS server, so it worked fine in the one-machine case. AFAIR some NFS clients had that behavior that locks were respected locally, even if they were not propagated to the server. Regards, Markus Schaber
Re: Svn mergeinfo appearing on sub-directories
On Thu, Jun 09, 2011 at 02:51:47PM +0100, Echlin, Jamie wrote: > > Hmmm... > > Does the parent of the offending directory have > > non-inheritable mergeinfo? > > (Mergeinfo entries that have an asterisk appended are not > > inheritable.) > > Hi Stefan... > > Before the merge only the source (/trunk) and target > (branches/topic-XYZ) have mergeinfo, not parents or sub-directories of > either. > > The source and target both have two rev ranges for a single branch with > an asterisk, but this is for a completely unrelated branch... It would be interesting to see if you can reproduce the problem in your environment with the 1.7.0-alpha1 release. This release should become available during the next few days. Once it is available, could you try to repeat the merge with a 1.7.0-alpha1 client into a working copy of the appropriate old revision? If you can reproduce it with 1.7, and have the time, could you try to come up with a reproduction recipe that produces the problem, starting from an empty repository? Maybe you've found a bug in processing of non-inheritable mergeinfo. Having an isolated test case for this problem would help a lot. If you don't have time for all that, that's fine. Someone might eventually try to reproduce this problem based on information you've already provided and write a script or regression test. In any case, I think we should file an issue to keep track of this.
RE: Strange merge behaviour
> I'm facing a problem where I get items modified by a merge although > there should be nothing to merge at all. > > I create a new branch from trunk. > I checkout from that new branch. > I merge from trunk into the new branch. > > [ No intermediate commit did happen as I'm doing this on a personal > backup copy of the repository. ] > > svn status now shows some modified elements, and if I look at them > with svn diff, I get something like > > Property changes on: path/to/file > ___ > Modified: svn:mergeinfo >Merged /project/trunk/path/to/file:r1234 > > Why is this and how can I get rid of this strange behaviour? > > Thanks... Check to see if prior to your merge that file already had merge info on it. If it does then the merge info will be updated on that item, even if that item is not modified by the diff. BOb
RE: Svn mergeinfo appearing on sub-directories
> It would be interesting to see if you can reproduce the > problem in your environment with the 1.7.0-alpha1 release. Hi Stefan... I will certainly give that a try. > If you can reproduce it with 1.7, and have the time, could > you try to come up with a reproduction recipe that produces I totally understand the value of this, and have done this for similar issues in the past. But the complexity of the mergeinfo involved may make this impractical at the moment. Normally I'd try to reproduce in as simple case as possible to try to understand the issue, but this case may actually require some understanding before attempting to reproduce outside the repo. Cheers, jamie === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
Re: possible mechanism of repo corruption
On Thu, Jun 09, 2011 at 04:32:26PM +0200, Markus Schaber wrote: > Hi, > > > Von: Stefan Sperling [mailto:s...@elego.de] > > > If your Apache server is handling requests via threads (rather than > > forking > > processes) this might explain why you never saw this problem with just > > dav. > > The threads can synchronise via mutexes which live in the same process > > address space. But separate processes require file locking for proper > > synchronisation. > > If there's only one machine running the Apache server, and the svnserve > is on a different one, then another hint may be that the apache machine > locked the files locally but not on the NFS server, so it worked fine in > the one-machine case. AFAIR some NFS clients had that behavior that > locks were respected locally, even if they were not propagated to the > server. Yes, I've seen examples of this. Problems can happen either because one side doesn't support locks, or because the lock tokens used are not compatible. I've seen problems with incompatible lock tokens between Linux and FreeBSD machines some years ago. Both support locking but it wasn't interoperable when I tried. This might since have been fixed (hopefully). I've also seen NFS clients that do not support sending lock tockens to the server but still present locks to local processes accessing the NFS-mounted filesystem. E.g. OpenBSD NFS clients behave like this and do not support sending locks to the server. But an OpenBSD server supports locking for clients which do support it, but I'm not sure what clients this is compatible with. In general, exposing FSFS repositories over NFS should only be done if file locking is supported and the locking implementations of NFS client and server are known to be fully interoperable.
RE: hook permissions, visualsvn, windows
Lorenz wrote: >> that doesn't look like a windows batch file to me. >> You sure that runs from the windows command line? >> >> Doing so on win xp gives me errors about the "REPOS=$1" and >> "REV=$2" lines. And the when I correct the syntax the call to svn >> results in svn trying to update $REPOS (literally!) and >> D:/Websites/wwwsite1 >> >> Anyway, the syntax of the update command is: >> >> svn up >> >>no repository url/path required/allowed. I wondered about that but it worked on my old server and yes, it did run from the command line. It complained about the lines starting with # but ignored them. Looking more closely, it appears to have complained abou the REPOS=$1 line as well but ignored that, too. Finally, it seems to have ignored the "$REPOS" in the update command and updated the listed working copy. I have now shortened the file to a single line: "C:\Program Files (x86)\VisualSVN Server\bin\svn" up D:/websites/wwwsite1 That runs from the command line this time without any comments or warnings. So, that's good. It still doesn't run when I commit a change to the repository, though. I did, though, get an error in the event log this time. It seems to be complaining about a username/password being unknown or incorrect. The user name displayed is my own. It's a network account that happens to be an administrator on the local machine. It occurs to me, however, that I installed VisualSVN without right-clicking and selecting "Run as Administrator." Should I have? Would that produce the problem I'm seeing? -- Henry
Re: hook permissions, visualsvn, windows
On Thu, Jun 9, 2011 at 11:05, Henry Hartley wrote: > Lorenz wrote: >>> that doesn't look like a windows batch file to me. >>> You sure that runs from the windows command line? >>> >>> Doing so on win xp gives me errors about the "REPOS=$1" and >>> "REV=$2" lines. And the when I correct the syntax the call to svn >>> results in svn trying to update $REPOS (literally!) and >>> D:/Websites/wwwsite1 >>> >>> Anyway, the syntax of the update command is: >>> >>> svn up >>> >>>no repository url/path required/allowed. > > I wondered about that but it worked on my old server and yes, it did run from > the command line. It complained about the lines starting with # but ignored > them. Looking more closely, it appears to have complained abou the REPOS=$1 > line as well but ignored that, too. Finally, it seems to have ignored the > "$REPOS" in the update command and updated the listed working copy. > > I have now shortened the file to a single line: > > "C:\Program Files (x86)\VisualSVN Server\bin\svn" up D:/websites/wwwsite1 > > That runs from the command line this time without any comments or warnings. > So, that's good. It still doesn't run when I commit a change to the > repository, though. > > I did, though, get an error in the event log this time. It seems to be > complaining about a username/password being unknown or incorrect. The user > name displayed is my own. It's a network account that happens to be an > administrator on the local machine. It occurs to me, however, that I > installed VisualSVN without right-clicking and selecting "Run as > Administrator." Should I have? Would that produce the problem I'm seeing? Does your repository require authentication for read operations (like an update)? If so, the account that the hook script is running under (the same one that VisualSVN Server is running under, probably Network Service) doesn't have credentials cached, so the hook is being prompted for credentials. Pass valid credentials to svn update with --username and --password in your hook & see what happens.
Re: svnshell-like client
> > From: Ryan Schmidt > >> cadaver(1) allows browsing WebDAV HTTP servers from the command line. > >> It doesn't do everything you want (but you might be able to use it as > >> a starting point (if you enable http:// access to your repositories)). > > > > I was going to suggest WebDAV too, only I was going to recommend using your >OS > > > WebDAV client (assuming your OS has one) to mount the repository, then > > using > > your OS shell or disk browser to examine it as desired. I just tried this > > on >Mac > > > > > OS X and it worked fine. No need to install additional software. (Though >there > > > would be the need to enable WebDAV on your repository server, if you're not > > already using http to serve the repository.) > > On Jun 8, 2011, at 00:04, Rick Varney wrote: > > > Hello Ryan, > > > > Interesting! I'd like to play with this, but I have not yet enabled > > http:// > > access to my repository - we're still using svnserve for now. I'm trying > > to >use > > > Konqueror on Linux to connect to: > > > > webdav://svn.apache.org/repos/afs/ > > > > But without success - maybe WebDAV is not enabled for this server? Are you > > aware of any WebDAV enabled servers on the web I could play with? > > > > I emailed you off the subversion users list because I didn't think this >question > > > would be of general interest. Feel free to CC the list if you feel it is. > > > > Thanks for the suggestion! > > > > Rick > From: Ryan Schmidt > To: Rick Varney > Sent: Tue, June 7, 2011 10:18:27 PM > Subject: Re: svnshell-like client > > All Subversion servers serving over http or https are WebDAV enabled; > the Subversion Apache module is a layer on top of WebDAV; WebDAV is a > prerequisite for its use. > > Accessing http://svn.apache.org/repos/afs/ in a web browser says it's 404 not >found. > > Perhaps you meant http://svn.apache.org/repos/asf/ ? Connecting to that in > the > Mac OS X Finder, I am able to browse it. > > Even if you continue to use svnserve for your developers, you could >simultaneously > > enable http and/or https access so that you can browse by WebDAV. You could > even make the web access read-only and only allow writes via svnserve. > > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.html > I decided that maybe this would be educational to others like me, so I am posting it to the list. If I mount the the repository as a file system using a WebDAV client, how would I accomplish doing an svn info on a file, for example? I assume that svn info would think files in the mounted file system are unversioned files. Is there a way to discover the URL of files mounted in this way? Regards, Rick
Re: svnshell-like client
On Jun 9, 2011, at 11:26, Rick Varney wrote: > If I mount the the repository as a file system using a WebDAV client, > how would I accomplish doing an svn info on a file, for example? I assume > that svn info would think files in the mounted file system are unversioned > files. Right, simply running svn commands here wouldn't work. > Is there a way to discover the URL of files mounted in this way? Presumably you know the URL, since you used it to connect to the server in the first place. You could write shell aliases or scripts to help you get info or logs from the original repository URL.
Re: svnshell-like client
> On Tue, May 31, 2011 at 5:46 PM, Les Mikesell wrote: > > >> Not quite what you want, but viewvc gives a reasonable way to explore a > >repository (especially remotely) with only a web browser and once you > >understand the layout you can plug the path you need into your normal svn > >client. > > On Fri, 03 Jun 2011 19:57:03 -0700, Nico Kadel-Garcia nka...@gmail.com wrote: > > Almost any web client can provide interactive command line access to a > >Subversion HTTP or HTTPS enabled repository, with the WebDAV features > built >in >there. I find "lftp" particularly useful for command line > access, and use >TortoiseSVN from a Windows client to have the best > user interface in the >business for client-side HTTP access. You can > use svnserve, HTTP, HTTPS, >svn+ssh, or file based access. > > (I really, really don't recommend file based access for clients.) I think you have some good reasons for this last statement, but they are not obvious to me. Could you elaborate some more on why you don't recommend this?
Re: svnshell-like client
On Jun 9, 2011, at 11:35, Rick Varney wrote: >> (I really, really don't recommend file based access for clients.) > > I think you have some good reasons for this last statement, > but they are not obvious to me. Could you elaborate some > more on why you don't recommend this? file:///-protocol-based access is not appropriate for a production repository, because any user can circumvent any hook scripts or access controls you've put in place, and can even delete the entire repository with a couple keystrokes. file:/// protocol is for testing purposes only, before you've gotten around to setting up a server process. The main point is that file access to the repository must be restricted to just the user the repository is being served under, so that regular users do not have that level of access. But it's probably fine if you have some admin scripts that run on the same server and under that same user and use the file:/// protocol for those.
SVN Best Practices
I'm working on a document that states the industry's best practices for SVN and would appreciate some guidance. Can anyone share or direct me to a good site that has useful information that engineers have discovered while working with SVN? I know I can read the SVN manual and did, but looking for real life experiences. I did a google search for some information but a helping hand to further my research would be appreciated. Thanks in advance, - Phillip Montgomery | Motorola Mobility Homes IT Support
Single Sign on for read-only Subversion access via HTTP
We use LDAP authentication + Subversion ACL We would like to let the read-only access users by-pass LDAP is that possible ? is there a single-sign0n module perhaps ? We also need to set ignore case in http.conf (we did this but http crashes when enabling the non-LDAP access for a specific repository Phil
Re: Single Sign on for read-only Subversion access via HTTP
Hi, If your LDAP auth is backed by Kerberos, e.g., Active Directory, then you can use Kerberos is setup single sign-on via the Apache mod_auth_kerb. Take care, Michael. On Thu, Jun 9, 2011 at 10:39, Phil Pinkerton wrote: > We use LDAP authentication + Subversion ACL > > We would like to let the read-only access users by-pass LDAP > > is that possible ? is there a single-sign0n module perhaps ? > > We also need to set ignore case in http.conf (we did this but http crashes > when enabling the non-LDAP access for a specific repository > > > Phil > > -- = Michael Rohan Stone Pillar Technologies =
Re: Mixed authentication and WebSVN on same host
Hi Konstantin, Thanks for your reply! I ended up settling for black-and-white access for WebSVN, manually hiding private repositories This is what I ended up doing: > ServerAdmin p...@fusi0n.org > ServerName svn.eratech.ca > DocumentRoot /usr/share/websvn > DirectoryIndex wsvn.php > Alias /templates /usr/share/websvn/templates > Alias / /usr/share/websvn/wsvn.php/ > > Options -Indexes +FollowSymlinks +MultiViews > #Require valid-user > #Satisfy Any > #AuthType Digest > #AuthName "Subversion Repositories" > #AuthUserFile /var/repos/.svnpasswd.htdigest > #AuthzSVNAccessFile /var/repos/.svnpasswd > > > > NameVirtualHost *:443 > > ServerAdmin p...@fusi0n.org > ServerName svn.eratech.ca > SSLEngine on > SSLCertificateFile /etc/ssl/svn.eratech.ca.crt > SSLCertificateKeyFile /etc/ssl/svn.eratech.ca.key > SSLCertificateChainFile /etc/ssl/PositiveSSL.ca-bundle > > DAV svn > SVNListParentPath on > SVNParentPath /var/repos > AuthzSVNAccessFile /var/repos/.svnpasswd > Satisfy Any > Require valid-user > AuthType Digest > AuthName "Subversion Repositories" > AuthUserFile /var/repos/.svnpasswd.htdigest > SSLRequireSSL > > > On Thu, Jun 9, 2011 at 3:32 AM, Konstantin Kolinko wrote: > 2011/6/9 Pier-Luc Petitclerc : > > The problem I have with that is related to the user authentication. I > have > > read that mixed authentication (anonymous vs "registered") is possible > with > > authz and that's what I tried implementing. > > Read The Book [1], as well as HTTPD manuals. [2] > > 1) To mix anonymous and non-anonymous auth (i.e. allow read-only svn > access for anons) you configure different access rules for different > HTTP methods. I.e. GET etc. will go without authentication, but > REPORT, PUT, ... will require authentication. [1] has an example. > > 2) "Satisfy Any" is wrong. You should be careful with it. (If you have > Allow/Deny statements elsewhere it will be enough to satisfy auth > requirements). > See [2] and you'd better configure "Satisfy All". > > [1]: http://svnbook.red-bean.com/ > [2]: http://httpd.apache.org/docs/ > > > > > However, the problem I'm having now is that Apache does not ask users for > > credentials presumably due to the "Satisfy Any" statement. Unless I am > > mistaken, that is how Authz work - to grab usernames off Apache's > > authentication and associate it with the ACL specified in > > AuthzSVNAccessFile... well, that's not working. I've tried many > combinations > > to no avail... so is there someone who has configured something similar? > > > You can configure an access log and look there for what requests and > responses are. When apache requests auth it is HTTP response code 401. > > Best regards, > Konstantin Kolinko > -- - pL No trees were killed to send this message, but a large number of electrons were terribly inconvenienced.
Merging Properties?
Hello, Suppose I have a file on trunk called file.txt. I put a property on it, say color with the value red. Now I copy trunk to a branch B. On branch B I change file.txt's color property to green. Now independently on trunk, I also change file.txt's color property to green. When I merge the branch B back to trunk, I get a merge conflict, even though both the branch and the trunk are trying to change the property to the same value. Is this expected or a bug or ...? I'm using TortoiseSVN 1.6.15 on Windows which I think is using Subversion 1.6.16. Thanks. BN
Re: problem installing subversion without berkeley DB
On Thu, Jun 9, 2011 at 9:45 AM, ZXGLOSTER118, ext < ext.zxgloster...@astrium.eads.net> wrote: > Hi, > > I’m trying to install subversion 1.6.15 without bekerley DB (which is not > installed). > > I have launch the command ./configure –without-berkeley-db but when doing > make install the following error occurs: > > grep: can't open /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la > > Can't open /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la > > libtool: link: `/usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la' is not a valid > libtool archive > > make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1 > > > > How could I resolve this error ? > > > > > First: if you're building by hand, grab 1.6.17 for the latest updates. Second. Why does it think Berkeley DB is install in /usr/local/BerkeleyDB.4.2? You should be able to run "sh -x configure --without-berkeley-db" or something like it and see what happens.
RE: Merging Properties?
Subversion only sees that the changes were made independently on precisely the same item. It knows nothing of the content or impact of that change within your code and, rightly so, will identify this situation as a conflict. Since your using Tortoise, this is easy enough to deal with in the situation you describe. Right-click, edit conflicts, use whichever block of text you please, mark as resolved, test the code, commit the merge, and be on your merry way. -Tim -Original Message- From: Brian Neal [mailto:bgn...@gmail.com] Suppose I have a file on trunk called file.txt. I put a property on it, say color with the value red. Now I copy trunk to a branch B. On branch B I change file.txt's color property to green. Now independently on trunk, I also change file.txt's color property to green. When I merge the branch B back to trunk, I get a merge conflict, even though both the branch and the trunk are trying to change the property to the same value. Is this expected or a bug or ...?
RE: Merging Properties?
I'll forward this to the hive... My statement stands on how Subversion sees your changes. Subversion can't know if changing the properties to "green" simultaneously in different branches is trivial or not. A human has to know the difference. More experienced users can chime in her if this is a correct interpretation or not. If you have hundreds of files in this situation, I'd suggest keeping your branches in tighter sync through more frequent merge operations (from trunk to branch, especially). To solve the current situation, write a script. My two cents. -Tim -Original Message- From: Brian Neal [mailto:bgn...@gmail.com] Sent: Thursday, 09 June 2011 9:16 PM To: Sulser, Timothy (IFPRI) Subject: Re: Merging Properties? On Thu, Jun 9, 2011 at 9:05 PM, Sulser, Timothy (IFPRI) wrote: > Subversion only sees that the changes were made independently on > precisely the same item. It knows nothing of the content or impact of > that change within your code and, rightly so, will identify this > situation as a conflict. I guess I don't follow. If the property values are the same, why is this flagged as a conflict? There is no conflict. What is the reasoning behind this behavior? Or is this just something that hasn't had any attention given to it? (I gather not many people use properties). > > Since your using Tortoise, this is easy enough to deal with in the > situation you describe. Right-click, edit conflicts, use whichever > block of text you please, mark as resolved, test the code, commit the > merge, and be on your merry way. Except there are hundreds of files like this unfortunately. > > -Tim Thanks, BN
Re: Strange merge behaviour
Am 09.06.2011 16:30, schrieb Sulser, Timothy (IFPRI): I don't think you'll be able to get rid of that behavior unless you change your strategy for making personal backups. The personal backup was made solely to reproduce the problem in a clean environment, without interference from other devs. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)211 56623 316 Configuration Manager | Fax: +49 (0)211 56623 450 Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com Wanheimerstraße 68 | Web: http://www.de.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Strange merge behaviour
Am 09.06.2011 16:42, schrieb Bob Archer: Check to see if prior to your merge that file already had merge info on it. If it does then the merge info will be updated on that item, even if that item is not modified by the diff. OK, but how do I get rid of this, it's really irritating for the users. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)211 56623 316 Configuration Manager | Fax: +49 (0)211 56623 450 Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com Wanheimerstraße 68 | Web: http://www.de.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
RE: SVN Best Practices
> I'm working on a document that states the industry's best > practices for SVN and would appreciate some guidance. Can > anyone share or direct me to a good site that has useful > information that engineers have discovered while working with > SVN? I know I can read the SVN manual and did, but looking > for real life experiences. I did a google search for some > information but a helping hand to further my research would > be appreciated. Did you see: http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html Best regards Andreas -- Andreas Tscharner -- "Intruder on level one. All Aliens please proceed to level one." -- Call in "Alien: Resurrection" CT-Dienstleistungen neu bei Wenzel Metromec === Haben Sie einen Prototyp ohne Zeichnung oder Konstruktionsmodell? Suchen Sie in Ihren Bauteilen Materialschäden, Risse und Poren? Dann sind unsere neuen Dienstleistungen im Bereich der Computertomographie die perfekte Lösung für Ihre Anforderungen! Testen Sie uns und unsere neue WENZEL exaCT Anlage. Zögern Sie nicht und nehmen Sie noch heute mit uns Kontakt auf. mailto:c...@metromec.ch?subject=CT-Dienstleistungen
