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 Location / DAV svn ./Location, 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 Location /svn DAV svn . /Location is worked. Thanks
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 Location / DAV svn .../Location, 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 Location /svn DAV svn ... /Location 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 Location 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
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: SVN 1.8.1 Errors - Show Log and Commit New Files
Geoff Field geoff_fi...@aapl.com.au 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
On Tue, Aug 13, 2013 at 12:52 PM, Okabayashi, Hirotsugu hirotsugu.okabaya...@jp.sony.com 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: 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: 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: 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 ro...@naumenko.ca 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 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: 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 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 jo...@rotair.com 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
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
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
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
-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
On Tue, Aug 13, 2013 at 4:12 PM, John Maher jo...@rotair.com 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
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 jo...@rotair.com 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
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: SVN 1.8.1 Errors - Show Log and Commit New Files
From: Philip Martin Sent: Tuesday, 13 August 2013 19:59 PM Geoff Field geoff_fi...@aapl.com.au 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: Location /Subversion 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: SVN 1.8.1 Errors - Show Log and Commit New Files
Geoff Field geoff_fi...@aapl.com.au 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: Location /Subversion 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
