Re: About subversion configure with apache2
On Aug 13, 2013, at 02:09, Steven Wee wrote: > I configure subversion works with apache2,and configure the > virtual host for working, I want used the “SVNListParentPath” option to show > all repository, and I configure the virtual host at apache2 used > DAV svn …, when I visit the domain, I response the message: “403 > Forbidden This website requires you to log in.”, can you help me to resolve > this problem? > > BTW: I used DAV svn … is worked. > What version of mod_dav_svn are you using on the server? What version of Subversion client are you using to access it? What version of Apache httpd 2? What is the DocumentRoot and SVNParentPath for this virtual host? I just want to be sure that they do not overlap. Are you using authz in the server configuration? I found this issue which might be related if you are: http://subversion.tigris.org/issues/show_bug.cgi?id=2753
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Geoff Field writes: >> When I try to reproduce the problem I get a HEAD request that >> generates >> "404 not found" rather than "401 unauthorized". What sort of >> authentication have you configured? Are you using path-based authz? > > Here's what I think is the relevant section of our httpd.conf: > > > DAV svn > SVNParentPath L:/Subversion/Repositories > SVNAutoversioning on > > AuthType SSPI > AuthName "Subversion repositories" > Require valid-user > SSPIAuth On > SSPIAuthoritative On > SSPIDomain AAPL > SSPIOfferBasic On > SSLRequireSSL > # SSPIUsernameCase lower ## Breaks authentication > # SSPIPerRequestAuth Off ## This breaks Apache2 > > AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf > > Note that we're running Apache 2.0. Here are the exact details from > the server's "Services" applet: If you could disable AuthzSVNAccessFile, or move the test repository to another Location that doesn't have authz, and then try the commit we could determine whether Subversion's authz is the problem. The apache error log may also have some relevant information about the 401. I don't have an Apache 2.0 build to test so I can't determine whether the problem is related to using 2.0. Perhaps something in 2.0 is causing the 401 instead of a 404. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
> From: Philip Martin > Sent: Tuesday, 13 August 2013 19:59 PM > Geoff Field writes: > >> -Original Message- > >> From: Philip Martin > >> Sent: Monday, 12 August 2013 18:57 PM Geoff Field writes: > >> > >> I can't reproduce that. Can you look in the apache log > files to see > >> the failed request? Can you reproduce the problem over http? Can > >> you provide a network trace? > > > > I have emailed Philip and Lieven directly with the network > trace file > > as it's a bit big (600-odd K) for a mailing list. > > It's an https trace so not much use to me. That's a shame. > > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "PROPPATCH > > > /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8 > > 97 HTTP/1.1" 401 580 > > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "PROPPATCH > > > /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8 > > 97 HTTP/1.1" 207 475 > > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "CHECKOUT > > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 401 580 > > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "CHECKOUT > > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439 > > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "HEAD > > /Subversion/Playground/trunk/test4.txt HTTP/1.1" 401 - > > When I try to reproduce the problem I get a HEAD request that > generates > "404 not found" rather than "401 unauthorized". What sort of > authentication have you configured? Are you using path-based authz? Here's what I think is the relevant section of our httpd.conf: DAV svn SVNParentPath L:/Subversion/Repositories SVNAutoversioning on AuthType SSPI AuthName "Subversion repositories" Require valid-user SSPIAuth On SSPIAuthoritative On SSPIDomain AAPL SSPIOfferBasic On SSLRequireSSL # SSPIUsernameCase lower ## Breaks authentication # SSPIPerRequestAuth Off ## This breaks Apache2 AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf Note that we're running Apache 2.0. Here are the exact details from the server's "Services" applet: Apache/2.0.54 (Win32) DAV/2 mod_ssl/2.0.55 OpenSSL/0.9.8 SVN/1.2.3 mod_python/3.1.3 Python/2.3.5 PHP/5.0.4 mod_auth_sspi/1.0.3 I'm trying (as a background task from my regular job) to upgrade to Apache 2.2, but it's proving to be a bit of a learning experience. Part of our issue is that the people who originally set it all up (and who started doing the upgrade once upon a time) have moved on to other jobs. Another part is that maintenance of SVN is a very small part of my job - so small it's under "other duties as directed" in the position description, along with numerous other tasks. (I guess many of us on this mailing list will be in similar positions, too.) I'm still learning, even 25+ years into my work life... Thanks for your patience. Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
RE: Strange behavior
Thanks Andrew, I started going through your steps and discovered something. My repository is called either iERP85_v2 or iERP85_V2. Visual SVN reports the latter but the former works with the client. Don't know which nor why one product chooses one over the other. My mistake was assuming I make a mistake with the repository. The mistake I actually made was trusting visual svn server. Although svn did report the smaller v it can be difficult to notice. So I created two branches for two new features I am working on. I'll see how they go. Thanks again JM -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 13, 2013 10:27 AM To: John Maher; users@subversion.apache.org Subject: RE: Strange behavior > -Original Message- > From: John Maher [mailto:jo...@rotair.com] > Sent: Tuesday, August 13, 2013 9:40 AM > To: Thorsten Schöning; users@subversion.apache.org > Subject: RE: Strange behavior > > Hi Thorsten > > A good response to a less than good post. People could take lessons > from you. > > Actually, its been a frustrating week. Sometimes subversion accepts > the wrong slash in a path, other times it does not. Sometimes it > enforces case sensitivity in a url other times it does not. Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s "c:/program files/subversion", which helps when feeding paths between CMD commands and svn commands. > Follow the > book on how it instructs to import a project then it becomes > impossible to merge and branch. That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it. > And now for the second time I must discard my repository along with > all the history I've accumulated. Yes you can say frustrating, > bordering on maddening. Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example: Revision 10 of /trunk is your "200 commands" to import the initial baseline. 1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10 Or if you want to roll trunk back to rev 10: 1. svn rm svn://server/trunk 2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later. Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial "200 commands" of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea. > > I got a good laugh from: > "Of course it can, just copy your 200 commands line by line one after > another into a batch file." I know it was a humorous comment, but... Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *g*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much. Good luck, and keep up the perseverance. "That which doesn't kill you, probably leaves you crippled and weak" (or something to that effect.)
RE: Strange behavior
Thanks Johan, I'll have to try it. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, August 13, 2013 11:42 AM To: John Maher Cc: Ryan Schmidt; Subversion Users Subject: Re: Strange behavior On Tue, Aug 13, 2013 at 4:12 PM, John Maher wrote: > Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are > really local global-ignores and I have to copy the config file over to anyone > who may import. > As of version 1.8 (for the svn client), there is a new feature called "Repository Dictated Configuration" [1], which you can use to set a global-ignores that will be applied by all standard 1.8 clients. It works by setting an svn:global-ignores property on a directory in your repository, which then applies to the entire subtree under that directory. However, I'm not sure if that feature applies to 'svn import' (because it doesn't have a working copy). I guess someone will have to try it :-). [1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config -- Johan
Re: Strange behavior
On Tue, Aug 13, 2013 at 4:12 PM, John Maher wrote: > Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are > really local global-ignores and I have to copy the config file over to anyone > who may import. > As of version 1.8 (for the svn client), there is a new feature called "Repository Dictated Configuration" [1], which you can use to set a global-ignores that will be applied by all standard 1.8 clients. It works by setting an svn:global-ignores property on a directory in your repository, which then applies to the entire subtree under that directory. However, I'm not sure if that feature applies to 'svn import' (because it doesn't have a working copy). I guess someone will have to try it :-). [1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config -- Johan
RE: Strange behavior
> -Original Message- > From: John Maher [mailto:jo...@rotair.com] > Sent: Tuesday, August 13, 2013 9:40 AM > To: Thorsten Schöning; users@subversion.apache.org > Subject: RE: Strange behavior > > Hi Thorsten > > A good response to a less than good post. People could take lessons > from you. > > Actually, its been a frustrating week. Sometimes subversion accepts > the wrong slash in a path, other times it does not. Sometimes it > enforces case sensitivity in a url other times it does not. Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s "c:/program files/subversion", which helps when feeding paths between CMD commands and svn commands. > Follow the > book on how it instructs to import a project then it becomes impossible > to merge and branch. That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it. > And now for the second time I must discard my > repository along with all the history I've accumulated. Yes you can > say frustrating, bordering on maddening. Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example: Revision 10 of /trunk is your "200 commands" to import the initial baseline. 1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10 Or if you want to roll trunk back to rev 10: 1. svn rm svn://server/trunk 2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later. Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial "200 commands" of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea. > > I got a good laugh from: > "Of course it can, just copy your 200 commands line by line one after > another into a batch file." I know it was a humorous comment, but... Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *g*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much. Good luck, and keep up the perseverance. "That which doesn't kill you, probably leaves you crippled and weak" (or something to that effect.)
Re: Strange behavior
Guten Tag John Maher, am Dienstag, 13. August 2013 um 15:39 schrieben Sie: > Follow the book on how it instructs to import a project then > it becomes impossible to merge and branch. Branching is always possible and always equally cheap regardless of what you did before, because it breaks down to a cheap copy operation with preserving history. The only thing which may cost time is updating/checking the new branch out. If you have merge problems because of your tests or whatever one solution may be just recording merge info. This way you can move and copy and delete things in any way you like and make subversion think that those changes are already applied to a selected directory without really applying them, meaning you won't get any merge conflicts now or later from the revisions you recorded as already merged. This may prevent re-creating your repo and losing history. http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Strange behavior
Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import. I also appreciate your description of the in-place import. I like the idea of being able to un-add a file. That allows you to experiment with wildcards without fear of damaging the repository. Adding a file to the repository that you do not wish can be considered damaging if it guarantees a merge conflict every time. Thanks again JM -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Monday, August 12, 2013 5:25 PM To: John Maher Cc: Subversion Users Subject: Re: Strange behavior On Aug 12, 2013, at 09:17, John Maher wrote: > Thanks for your help, but I still do not know how to get this to work. > Perhaps I should give a little background. The project that I mentioned in > my original post was a test project created just to learn how to get > subversion to work. The production code that I wish to put in one repository > resides in 62 directories that have over 2000 files in them of which only > some of them can be included otherwise merging becomes impossible. The whole > point of this exercise is to get merging to work since it causes unnecessary > difficultly to try to separate new features with bug fixes in a single > branch. But this is all I could get to work. Unfortunately no matter how > much I read (I read the first half of the book twice) and how much I checkout > and commit the tool fails to work for me. I'll let others address your merging questions, since I read the book before Subversion 1.5 was released, when merge tracking was introduced, which has simplified merging considerably. > And the only reason I have been complaining about the documentation is hoping > to point out areas where it is very unclear and misleading. Anyone who knows > how to use the tool will never catch on to the poorly written areas of the > documentation, they are biased. You NEED someone who doesn't know how to use > the tool to indicate areas that need to be addressed. I totally agree, and please continue doing this. I did originally learn Subversion by reading the book, so that was the basis for my praise of it, but I have learned many more things by reading years of messages on this list so sometimes it's hard for me to recall where a particular bit of knowledge came from. > Now the two suggestions I have are auto properties and in place import. The > links provided do not relate to my situation. I think when I said auto-props, I meant global-ignores. Sorry about that. They're related in that they're both considered when importing. I think I see why I said that: you wrote: > Does import work with the ignore property? It mentions it in the help, but I > do not know if the help is wrong. If properties need to be applied to a > working directory how do I use them with the import command BEFORE a working > copy exists? I was confusing the svn:ignore property with the global-ignores config file setting. The svn:ignore property is applied to a directory so that files inside it might be ignored (and which affects all users who might check out a working copy of this directory), and yes, that has to happen in a working copy. The global-ignores setting in your Subversion config file has a similar function but affects all working copies and import actions you perform, regardless what server is involved, and affects only you. > The provided link indicates properties that get set DURING the import. I > need to ignore files BEFORE the import. Like I originally stated, I need to > import SOME files. Importing compiler generated files OR user settings > causes problem and makes merging impossible thereby defeating some of the > benefits of using subversion. If this method will solve this problem can you > provide me with a link indicating how to do this? I can not find anything in > the book nor the provided link. If you could give me some keywords to search > for that would help also. I tried searching and all I find is questions > relating to different actions. > > I looked at the import command in the book and with the svn help command and > could not see how to use the svn:ignore. The import-in-place command works > on a single file. That would indicate I would need to issue the command > hundreds of times. Are you sure this is the only way? It would seem odd > that this toll does not provide a way to import an enterprise level > application without ignoring the compiler generated files. The in-place import does not operate on a single file; it is a procedure for importing any number of items within a directory. The example in the FAQ showed how to do an in-place import of four files in /etc. I'll try to explain in more detail. Let's say you have a directory of original files, and a repository you want to import t
RE: Strange behavior
One thing I forgot to mention is that yes, I know of Tortoise. I started with that. It works good for the most commonly used stuff, but falls short as a complete solution. So I really need to know how the "real" tool works. That is why I am struggling with the command line. JM -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, August 12, 2013 4:43 PM To: users@subversion.apache.org Subject: Re: Strange behavior Guten Tag John Maher, am Montag, 12. August 2013 um 20:57 schrieben Sie: > Otherwise there are > over 200 manual operations required just to create a repository. As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client. > The way some people praise subversion I would think this can be > automated. Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-) > But then again perhaps those are the people who use subversion for the > simplest of builds. Frustrating day, wasn't it? :-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Strange behavior
Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. I got a good laugh from: "Of course it can, just copy your 200 commands line by line one after another into a batch file." JM -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, August 12, 2013 4:43 PM To: users@subversion.apache.org Subject: Re: Strange behavior Guten Tag John Maher, am Montag, 12. August 2013 um 20:57 schrieben Sie: > Otherwise there are > over 200 manual operations required just to create a repository. As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client. > The way some people praise subversion I would think this can be > automated. Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-) > But then again perhaps those are the people who use subversion for the > simplest of builds. Frustrating day, wasn't it? :-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Strange behavior
Thanks Mark, that's an excellent shortcut. JM -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, August 12, 2013 4:05 PM To: John Maher Cc: Bob Archer; Edwin Castro; users@subversion.apache.org Subject: Re: Strange behavior On Mon, Aug 12, 2013 at 3:27 PM, John Maher wrote: > I couldn't find where it discusses the global config in the book, if it does > at all. And even if it does I doubt it would help because it won't tell me > where to find the file. Unless there is a command to edit it. I tried a > search and someone says there is a site-wide config (what I need) and a user > config but not where they are. I am using Windows XP and an having a > difficult time finding this file. > The configuration area is in the book in here: http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html The footnote links to the easiest way to find the file: %APPDATA%\Subversion Just enter that into the Windows Run dialog or the address bar of the file explorer and it will take you to the right folder where the configuration files are found. This is true for XP as well as Win 7. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Strange behavior
An excellent alternative. I will keep this in mind.
Thanks Andrew
JM
-Original Message-
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net]
Sent: Monday, August 12, 2013 3:52 PM
To: John Maher; users@subversion.apache.org
Subject: RE: Strange behavior
> -Original Message-
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Monday, August 12, 2013 3:27 PM
> To: Bob Archer; Edwin Castro; users@subversion.apache.org
> Subject: RE: Strange behavior
>
> Thanks Bob, that may be exactly what I am looking for. Something that
> would affect all the files without having to issue over 200 commands
> or build a dummy directory just for importing. Although that second
> suggestion provided by Andrew is definitely better than the first.
>
> I couldn't find where it discusses the global config in the book, if
> it does at all. And even if it does I doubt it would help because it
> won't tell me where to find the file. Unless there is a command to
> edit it. I tried a search and someone says there is a site-wide
> config (what I need) and a user config but not where they are. I am
> using Windows XP and an having a difficult time finding this file.
>
> I can't even find the name of it. If someone can provide that I could
> at least search for it and hope it has some clue inside as how to
> alter it.
>
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a "glob_ignores" option, or will try to read your global-ignores from
your local svn config file.
>From the script:
===
# If no glob_ignores specified, try to deduce from config file, # or use the
default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f "$ENV{HOME}/.subversion/config" )
{
open my $conf, "$ENV{HOME}/.subversion/config";
while (<$conf>)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
RE: Strange behavior
Thanks David. For the past week and a half I've been wrestling with this thing. Searching, reading, trying, back to searching. Time to switch gears but I needed to get over this hurdle. I'm now on the second repository I have to dispose of (and all the history with it) so I hope the 3rd time's the charm. Thanks again JM -Original Message- From: David Chapman [mailto:dcchap...@acm.org] Sent: Monday, August 12, 2013 3:49 PM To: John Maher Cc: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/2013 12:27 PM, John Maher wrote: > Thanks Bob, that may be exactly what I am looking for. Something that would > affect all the files without having to issue over 200 commands or build a > dummy directory just for importing. Although that second suggestion provided > by Andrew is definitely better than the first. > > I couldn't find where it discusses the global config in the book, if it does > at all. And even if it does I doubt it would help because it won't tell me > where to find the file. Unless there is a command to edit it. I tried a > search and someone says there is a site-wide config (what I need) and a user > config but not where they are. I am using Windows XP and an having a > difficult time finding this file. > > I can't even find the name of it. If someone can provide that I could at > least search for it and hope it has some clue inside as how to alter it. > > First link from Google (search was "windows xp subversion configuration file location", http://stackoverflow.com/questions/6310539/where-is-the-subversion-global-config-file-for-the-slik-svn-client-for-windows) sez: C:\Documents and Settings\%USERNAME%\Application Data\Subversion\config I no longer run on Windows XP, so I don't remember if this is the proper place for the file, but I have no reason to doubt it. For Windows 7 it's in: C:\Users\%USERNAME%\AppData\Roaming\Subversion\config Which I can confirm. In the "config" file, I have my global-ignores for Windows set to: global-ignores = *.obj *.lib *.map *.exe *.bak *.pdb *.ilk *.idb There might need to be a few more; it's been several years since I have imported existing code into my Subversion repositories. But you get the idea. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Balancing and proxing
On 2013/08/12 8:35 PM, Nico Kadel-Garcia wrote: > Nico Kadel-Garcia > Email: nka...@gmail.com > Sent from iPhone > > On Aug 9, 2013, at 20:12, Roman Naumenko > >> You mean this one (svn clustering)? >> http://www.wandisco.com/get?f=documentation/datasheets/DataSheet-Clustering.pdf >> >> It doesn't look like it's a simple loadbalancing architecture with a shared >> storage for repositories. > Right. Shared storage is very vulnerable to corrupting that single shared > back end. This seems to be a well thought out multi master setup, and should > be far more resilient for most environments. I tend to agree, although such direction limits scalability and administration 'kiss'-ness. >> There is some replication and synchronization involved, automatic failover, >> etc. >> Is anybody using it, what its like? >> >> --Roman > I'm working from the public specs. I'm not a Subversion master in my current > workplace, so lack the 3 hosts needed to really test it put. --Roman Naumenko ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
RE: Strange behavior
Thanks Bob. You have been very helpful. I didn't know that there was an html version of the book. I've been using the pdf version and haven't found a way to search that. The global ignores worked. Now I'm on to my third repository. I hate having to lose all the history I'm accumulated, but that's how it goes. Thanks again. JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:33 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior > Thanks Bob, that may be exactly what I am looking for. Something that > would affect all the files without having to issue over 200 commands > or build a dummy directory just for importing. Although that second > suggestion provided by Andrew is definitely better than the first. > > I couldn't find where it discusses the global config in the book, if it does > at all. > And even if it does I doubt it would help because it won't tell me > where to find the file. Unless there is a command to edit it. I > tried a search and someone says there is a site-wide config (what I > need) and a user config but not where they are. I am using Windows XP and an > having a difficult time finding this file. > > I can't even find the name of it. If someone can provide that I could > at least search for it and hope it has some clue inside as how to alter it. > Search for "global-ignores" in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea BOb > JM > > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Monday, August 12, 2013 3:02 PM > To: John Maher; Edwin Castro; users@subversion.apache.org > Subject: RE: Strange behavior > > > Thanks Edwin, > > > > That's exactly what I am trying to do. I was looking for a way for > > the tool to accomplish this. I'd be just as glad if someone tells > > me it is impossible, which I suspect it may be. Otherwise there are > > over > > 200 manual operations required just to create a repository. The way > > some people praise subversion I would think this can be automated. > > But then again perhaps those are the people who use subversion for > > the > simplest of builds. > > I'm not sure what you are asking for? An automated way to ignore files > you don't want check in? Or are you talking about import? > > I believe import respects global ignores if you have them set up in > your config file. > > BOb > > > > > > JM > > > > -Original Message- > > From: Edwin Castro [mailto:0ptikgh...@gmx.us] > > Sent: Monday, August 12, 2013 11:55 AM > > To: users@subversion.apache.org > > Subject: Re: Strange behavior > > > > On 8/12/13 6:17 AM, John Maher wrote: > > > Are you sure this is the only way? It would seem odd that this > > > toll does not > > provide a way to import an enterprise level application without > > ignoring the compiler generated files. > > > > In cases like this I perform a "clean" operation that removes > > compiler generated files. I would also remove any user specific > > files as by definition they should not be part of the repository. > > > > -- > > Edwin > > > >
Re: Cope with IPv6
Guten Tag Okabayashi, Hirotsugu, am Dienstag, 13. August 2013 um 10:52 schrieben Sie: > [Client] [...] > -Edit hosts file(Don't use DNS) > We registered the host name of NAT64 as SVN server. What does this mean? You can only map IP addresses to host names in this file. Does the host name of NAT64 map to the IP address of your SVN server or does NAT64 host name map to IP address of NAT64 host and you're accessing NAT64 as SVN server in Tortoise? Please post the relevant line in hosts file and the URL you use in Tortoise to access your repo with explanation of which host name resolves to which IP. Why should that be necessary in general? Your SVN server is IPv4 only, why should the IPv4 capable Windows 7 should access it using NAT64? If you want to use IPv6 with your Windows 7, make you SVN server available using IPv6. I don't understand what's the purpose of NAT64 in your scenario as "the server side" is SVN Server and is not capable of IPv6. Does your NAT64 translate IPv4 from Windows 7 to IPv6 internally, just to translate it back to IPv4 again externally to communicate with SVN Server? It would only make sense to use NAT64 to translate between your SVN server and AD, because Windows 7 can communicate with AD directly using IPv6, but SVN Server can't. Therefore I would suggest changing your hosts file on the Windows 7 client to remove whatever you map to NAT64 and let SVN Server and Windows Client communicate directly. Afterwards you need to make SVN Server IPv6 aware or AD IPv4 or both simply dual stack, which would be what I would do in your case as dual stack is and will be common and standard for years. NAT64 seems to only complicating things unnecessarily. From your description I don't think there's something wrong with Tortoise or Subversion, but with your network. But my experience with IPv6 is limited... Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Cope with IPv6
On Tue, Aug 13, 2013 at 12:52 PM, Okabayashi, Hirotsugu wrote: > Dear Daniel, > > Thank you for your reply and I'm sorry to be late. >> > > -Only with IPv6, the Operating system handle the authentication. >> > >> > What does this mean? > Sorry, let me explain about that in detail. > With IPv4, TSVN displays TSVN's authentication window. > With IPv6, however, TSVN displays Windows's authentication window(Windows > Security Window) > instead of TSVN's authentication window. TSVN displays Windows's authentication window when it tries to get list of repositories using Windows API, not Subversion libraries. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Geoff Field writes: >> -Original Message- >> From: Philip Martin >> Sent: Monday, 12 August 2013 18:57 PM >> Geoff Field writes: >> >> I can't reproduce that. Can you look in the apache log files >> to see the failed request? Can you reproduce the problem >> over http? Can you provide a network trace? > > I have emailed Philip and Lieven directly with the network trace file > as it's a bit big (600-odd K) for a mailing list. It's an https trace so not much use to me. > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "PROPPATCH > /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/897 > HTTP/1.1" 401 580 > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "PROPPATCH > /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/897 > HTTP/1.1" 207 475 > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "CHECKOUT > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 401 580 > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "CHECKOUT > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439 > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "HEAD > /Subversion/Playground/trunk/test4.txt HTTP/1.1" 401 - When I try to reproduce the problem I get a HEAD request that generates "404 not found" rather than "401 unauthorized". What sort of authentication have you configured? Are you using path-based authz? -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
RE: Cope with IPv6
Dear Daniel, Thank you for your reply and I'm sorry to be late. > > > -Only with IPv6, the Operating system handle the authentication. > > > > What does this mean? Sorry, let me explain about that in detail. With IPv4, TSVN displays TSVN's authentication window. With IPv6, however, TSVN displays Windows's authentication window(Windows Security Window) instead of TSVN's authentication window. > > You should at least provide the error message you get, but there are > > surely some more interesting details: How are your repos served, > > svnadmin, httpd, SSH? The mention of serf implies httpd, so you could > > provide some more details about if your are using proxys etc. I'm so sorry. I'll show you the detail. The error message is "Valid name, no data record of requested type.". (http://support.microsoft.com/kb/819124/en) See "WSANO_DATA (11004)". Both authenticated case and not authenticated case, TSVN doesn't work. TSVN displays the same error message. I could get the packets between the client and server. It apparently seems the client can communicate with the server setting IPv6. But there is no packet between the client and server on the way of processing(when authenticating). It's obviously hung up compared to IPv4's processing. I think client can't control the communication with the server when authenticating with IPv6. [Client] -TortoiseSVN 1.8.1 -Windows 7 Enterprise -Use common company proxy server with SSL -Authenticated with Active Directory Server(LDAP) -Edit hosts file(Don't use DNS) We registered the host name of NAT64 as SVN server. -Use IPv6(Dual Stack) [NAT64] -convert IPv4(Client Side) to IPv6(Server Side) -convert IPv6(Server Side) to IPv4(Client Side) -Not exist the host name in DNS -We can tell you more information if you need. [SVN Server] -RedHat 5.3 -Apache 2.2 setting of Active Directory(LDAP) -Subversion 1.7.5 -Use only IPv4 [Active Directory] -Use as LDAP Authentication -Use only IPv6 -We can tell you more information if you need. > > I'm none of the developers but from my understanding of IPv6 it > > shouldn't have any influence on the authentication itself as this is > > handled in layers above the addressing and communication. With IPv6, TSVN doesn't display TSVN's authentication window. I think that isn't caused by the addressing and communication but TSVN. TSVN's developer said that's the SVN API or serf's issue. Could you tell us if you know of that ? Regards, > -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: Thursday, August 08, 2013 10:56 PM > To: Okabayashi, Hirotsugu > Cc: users@subversion.apache.org > Subject: Re: Cope with IPv6 > > Forwarding Thorsten's answer to the OP. > > Thorsten Schöning wrote on Mon, Aug 05, 2013 at 09:58:20 +0200: > > Guten Tag Okabayashi, Hirotsugu, > > am Montag, 5. August 2013 um 09:17 schrieben Sie: > > > > > -Only with IPv6, the Operating system handle the authentication. > > > > What does this mean? > > > > > So, both authenticated case and not authenticated case, > > > TSVN doesn't work. TSVN display the same error message. > > > > You should at least provide the error message you get, but there are > > surely some more interesting details: How are your repos served, > > svnadmin, httpd, SSH? The mention of serf implies httpd, so you could > > provide some more details about if your are using proxys etc. > > > > I'm none of the developers but from my understanding of IPv6 it > > shouldn't have any influence on the authentication itself as this is > > handled in layers above the addressing and communication. > > > > Mit freundlichen Grüßen, > > > > Thorsten Schöning > > > > -- > > Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de > > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > > > Telefon...05151- 9468- 55 > > Fax...05151- 9468- 88 > > Mobil..0178-8 9468- 04 > > > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG > > Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
RE: About subversion configure with apache2
Note: please use "plain text" if possible for this list. > -Original Message- > From: Steven Wee [mailto:wmkm0...@gmail.com] > Sent: 13 August 2013 08:09 > To: users@subversion.apache.org > Subject: About subversion configure with apache2 > > Hi: > > I configure subversion works with apache2,and > configure the virtual host for working, I want used the > "SVNListParentPath" option to show all repository, and I > configure the virtual host at apache2 used DAV > svn ..., when I visit the domain, I response the > message: "403 Forbidden This website requires you to log > in.", can you help me to resolve this problem? Probably... > BTW: I used DAV svn ... > is worked. ...but it would help if you could provide more information about your current settings. Are you on windoze or *nix? Are you using http or https? What is the contents of your apache config files (clean out usernames and passwords before posting). How do you know your section is working? As a first guess, something else in your configuration file(s) is specifying authentication and authorisation but we cannot tell yet. ~ mark c
About subversion configure with apache2
Hi: I configure subversion works with apache2,and configure the virtual host for working, I want used the "SVNListParentPath" option to show all repository, and I configure the virtual host at apache2 used DAV svn ., when I visit the domain, I response the message: "403 Forbidden This website requires you to log in.", can you help me to resolve this problem? BTW: I used DAV svn . is worked. Thanks
