You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Geoff Field <Ge...@aapl.com.au> on 2013/08/02 02:06:14 UTC
SVN 1.8.1 Errors - Show Log and Commit New Files
I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its command-line basis. Our server has been running 1.2 and has not been changed (apart from Windows updates) for a LONG time.
(Yes, I know 1.2 is very old. However, we're an automotive company and changes to our tools can result in issues with customer approvals. Nonetheless, an upgrade is on the "to-do" list.)
Having said that, there are now MANY people posting to the TSVN mailing list about these two issues.
My platforms are 32-bit Windows 7 and Windows XP, but it has also been reported on 64-bit Windows.
First issue: When doing a "Show Log", the client says it can't contact the server and asks if people (including us) want to go offline, then puts up an HTTP 501 error.
Second issue: When committing new files, we get the message that one of them 'already exists'. I've found as a workaround that doing a clean checkout to a NEW directory, then copying everything across and running a commit will work - once.
After discussions on the TSVN mailing list, I've run command-line versions of both, with the following results (edited to hide customer names):
C:\Customer>svn log -v ./
svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio
n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
svn: E200007: Additional errors:
svn: E200007: The requested report is unknown.
C:\Customer>svn commit ./ -m "Committing via command line"
Adding (bin) DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDrlLimits.xlsx
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\Customer\DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDr
lLimits.xlsx' is out of date
svn: E175005: File 'OtherInputFiles/CustomerDrlLimits.xlsx' already exists
C:\Customer>svn --version
svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
Regards,
Geoff
--
Geoff Field
- 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
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 1, 2013, at 19:06, Geoff Field <Ge...@aapl.com.au> wrote:
> I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its command-line basis. Our server has been running 1.2 and has not been changed (apart from Windows updates) for a LONG time.
>
> (Yes, I know 1.2 is very old. However, we're an automotive company and changes to our tools can result in issues with customer approvals. Nonetheless, an upgrade is on the "to-do" list.)
It has been a longstanding policy of the Subversion project at any given time to support the latest major version and the previous major version. Therefore at this time Subversion < 1.7 is no longer supported. You should attempt to reproduce the issue with the server running Subversion 1.7 or later.
If you cannot upgrade the real server to 1.7 or later yet, you could set up a test server elsewhere, for example on your workstation, to see if upgrading would help with this problem. On the old server, you could "svnadmin dump" the repository into a file and then "svnadmin load" that file into your newer test server. Then see if you still experience the problem when you check out your working copies from the test server.
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Philip Martin <ph...@wandisco.com>.
Lieven Govaerts <lg...@apache.org> writes:
>> Yes, it does. It also affects mergeinfo:
>>
>> $ svn1.8 mergeinfo ^/ wc
>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/obj/repo/!svn/bc/1/A'
>> svn: E200007: Additional errors:
>> svn: E200007: The requested report is unknown.
>>
>> $ subversion/svn/svn mergeinfo ^/ wc
>> svn: E200007: Retrieval of mergeinfo unsupported by 'http://localhost:8888/obj/repo/A'
>>
>
> To be clear, this mergeinfo error is to be expected, and this patch
> has improved the error message. Or did you see a regression here?
> Lieven
The patch changes the error message and restores the 1.7 behaviour.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Lieven Govaerts <lg...@apache.org>.
On Mon, Aug 5, 2013 at 7:08 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Lieven Govaerts <lg...@apache.org> writes:
>
>> Can you test if attached patch fixes this issue?
>
>> Index: subversion/libsvn_ra_serf/util.c
>> ===================================================================
>> --- subversion/libsvn_ra_serf/util.c (revision 1510435)
>> +++ subversion/libsvn_ra_serf/util.c (working copy)
>> @@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
>> "server or an intermediate proxy does not accept "
>> "chunked encoding. Try setting 'http-chunked-requests' "
>> "to 'auto' or 'no' in your client configuration."));
>> + case 501:
>> + return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
>> + _("The requested feature is not supported by "
>> + "'%s'"), path);
>> }
>>
>> if (sline.code >= 300)
>
> Yes, it does. It also affects mergeinfo:
>
> $ svn1.8 mergeinfo ^/ wc
> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/obj/repo/!svn/bc/1/A'
> svn: E200007: Additional errors:
> svn: E200007: The requested report is unknown.
>
> $ subversion/svn/svn mergeinfo ^/ wc
> svn: E200007: Retrieval of mergeinfo unsupported by 'http://localhost:8888/obj/repo/A'
>
To be clear, this mergeinfo error is to be expected, and this patch
has improved the error message. Or did you see a regression here?
Lieven
> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Philip Martin <ph...@wandisco.com>.
Lieven Govaerts <lg...@apache.org> writes:
> Can you test if attached patch fixes this issue?
> Index: subversion/libsvn_ra_serf/util.c
> ===================================================================
> --- subversion/libsvn_ra_serf/util.c (revision 1510435)
> +++ subversion/libsvn_ra_serf/util.c (working copy)
> @@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
> "server or an intermediate proxy does not accept "
> "chunked encoding. Try setting 'http-chunked-requests' "
> "to 'auto' or 'no' in your client configuration."));
> + case 501:
> + return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
> + _("The requested feature is not supported by "
> + "'%s'"), path);
> }
>
> if (sline.code >= 300)
Yes, it does. It also affects mergeinfo:
$ svn1.8 mergeinfo ^/ wc
svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/obj/repo/!svn/bc/1/A'
svn: E200007: Additional errors:
svn: E200007: The requested report is unknown.
$ subversion/svn/svn mergeinfo ^/ wc
svn: E200007: Retrieval of mergeinfo unsupported by 'http://localhost:8888/obj/repo/A'
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Geoff Field
> Sent: Monday, 12 August 2013 10:20 AM
> > From: Philip Martin
> > Sent: Friday, 9 August 2013 18:10 PM
> > Geoff Field <Ge...@aapl.com.au> writes:
> >
> > > What about the Commit New Files error? Will this be fixed
> > with 1.8.2,
> > > do you think?
> >
> > I don't know how to reproduce it. You said:
> >
> > Second issue: When committing new files, we get the
> message that one
> > of
> > them 'already exists'. I've found as a workaround that doing a
> > clean
> > checkout to a NEW directory, then copying everything across and
> > running
> > a commit will work - once.
> >
> > but if I were to attempt to reproduce it I would do
> >
> > svnadmin create repo
> > svn co http://localhost/repo wc
> > cp /bin/true wc/foo # error message was for a binary file
> > svn add wc/foo
> > svn ci -mm wc
> >
> > but that works. That's no surprise because what I have done is
> > essentially what you say is a "workaround". Until you can come up
> > with a better description of how to reproduce the problem
> not much can
> > be done.
>
> Hello Philip,
>
> Sometimes the workaround works, sometimes it doesn't.
>
> Here's a log of a trial I have just done with a relatively
> fresh repository:
>
> C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
> A SVN_Test\test.txt
> Checked out revision 897.
>
> C:\>cd SVN_Test
>
> C:\SVN_Test>dir
> Volume in drive C is OSDisk
> Volume Serial Number is E49F-06D7
>
> Directory of C:\SVN_Test
>
> 12/08/2013 09:54 AM <DIR> .
> 12/08/2013 09:54 AM <DIR> ..
> 12/08/2013 09:54 AM 20 test.txt
> 1 File(s) 20 bytes
> 2 Dir(s) 160,268,779,520 bytes free
>
> C:\SVN_Test>copy test.txt test2.txt
> 1 file(s) copied.
>
> C:\SVN_Test>svn add test2.txt
> A test2.txt
>
> C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
> Adding test2.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
> svn: E175005: File 'test2.txt' already exists
>
> C:\SVN_Test>svn --version
> svn, version 1.8.1 (r1503906)
> compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows
>
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn
> network protocol.
> - with Cyrus SASL authentication
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV
> protocol using serf.
> - handles 'http' scheme
> - handles 'https' scheme
>
>
> C:\SVN_Test>
>
>
> Again, server version is 1.2 (yes, yes, I will update this at
> some stage in the near future, but apparently I also have to
> update Apache, which adds an extra layer of nuisance).
>
> This was the first time this repository had been touched since 2009.
>
> "test.txt" is a standard ASCII text file containing the
> sentence "A quick test file." with one carriage return.
>
> I hope this helps.
Oh yes, our server is running Windows Serve 2003, Enterprise Edition, SP2.
Regards,
Geoff
--
Apologies for the legal disclaimer auto-inserted by our servers:
- 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: How Big A Dump File Can Be Handled?
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Ben Reser
> Sent: Wednesday, 21 August 2013 17:07 PM
>
> On 8/20/13 11:29 PM, Geoff Field wrote:
> > Note that we have the old version 1.2.3 server software installed at
> > the C:\Program Files\Subversion location, and later versions
> > are stored under other locations, with the path set to point
> > to the new version.
> > I'm creating the new repositories with the old version for
> > those (hopefully rare) occasions when we need to switch back
> > to the old server version.
I should have added that any new repositories are being created with the new version of the tools. The old server software is only being kept around for legacy stuff.
> You can create old format repositories with the new tools via
> the following flags to create:
> --pre-1.4-compatible
> --pre-1.5-compatible
> --pre-1.6-compatible
> and with 1.8 (when we got a clue that the above was getting silly):
> --compatible-version
Handy to know. I recall seeing that sort of thing go flying by on the lists recently. One of these days I might have cause to use it.
> So you don't actually need to keep old versions of svnadmin
> around in order to do that.
But to work with the BDB repositories (just in case I ever have to again), I will still need the old version of svnadmin.
Given that we're one of those companies that get audited for process conformance (we're in the middle of one right now), it's better to be safe than sorry.
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- 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: How Big A Dump File Can Be Handled?
Posted by Ben Reser <be...@reser.org>.
On 8/20/13 11:29 PM, Geoff Field wrote:
> Note that we have the old version 1.2.3 server software installed at
the C:\Program Files\Subversion location, and later versions are stored
under other locations, with the path set to point to the new version.
I'm creating the new repositories with the old version for those
(hopefully rare) occasions when we need to switch back to the old server
version.
You can create old format repositories with the new tools via the
following flags to create:
--pre-1.4-compatible
--pre-1.5-compatible
--pre-1.6-compatible
and with 1.8 (when we got a clue that the above was getting silly):
--compatible-version
So you don't actually need to keep old versions of svnadmin around in
order to do that.
RE: How Big A Dump File Can Be Handled?
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Thorsten Schöning
> Sent: Wednesday, 21 August 2013 17:21 PM
> Guten Tag Geoff Field,
> am Mittwoch, 21. August 2013 um 08:29 schrieben Sie:
>
> > I've just realised that my concern was based on a power-of-2
> > limitation that means that a 32-bit signed integer would
> roll over at
> > the 2GB mark, with an unsigned roll-over at 4GB. It's possible the
> > Windows Server 2003 file system might have started to
...
> You didn't seriously thought that a Windows Server 2003 has
> such limitations?! If you installed on FAT32 you made
> something really wrong. ;-)
Ah, but it wasn't ME that did the install.
> > I really should have done it all using a scripting language of some
> > sort, too. I've told myself it's really too close to the
> end of the
> > process to think of *that* change now, except I've just managed to
> > quickly throw together a batch file to do the job.
...
> I created a powershell script to convert my 1.4 repos to 1.7
> some months ago, few months later we moved all repos to our
> Ubuntu development server and last month or so I upgraded svn
> to 1.8, without the possibility of a full dump/load because
> of my not working script anymore. One shouldn't start with
> platform specific console scripting anymore unless it's about
> really trivial stuff. It's to easy these days to change platforms.
To me, the copy is pretty trivial (if somewhat tedious) and unlikely to be repeated.
Changing platforms, however, would be distinctly NON-trivial in our circumstances. The servers are administered by a whole other department, with their platform inertia somewhat built-in.
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- 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: How Big A Dump File Can Be Handled?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Geoff Field,
am Mittwoch, 21. August 2013 um 08:29 schrieben Sie:
> I've just realised that my concern was based on a power-of-2
> limitation that means that a 32-bit signed integer would roll over
> at the 2GB mark, with an unsigned roll-over at 4GB. It's possible
> the Windows Server 2003 file system might have started to complain
> when it ran out of block indices/counters or some such, but there's
> no reason a 32GB+ file won't work if 4.1GB or more works.
You didn't seriously thought that a Windows Server 2003 has such
limitations?! If you installed on FAT32 you made something really
wrong. ;-)
> I really should have done it all using a scripting language of some
> sort, too. I've told myself it's really too close to the end of the
> process to think of *that* change now, except I've just managed to
> quickly throw together a batch file to do the job. I could probably
> have done it in python or some other scripting language, but batch
> files are quick and easy. Again, thanks Ben for the prompt to use
> my head a bit better (even though you didn't explicitly suggest this
> aspect).
I created a powershell script to convert my 1.4 repos to 1.7 some
months ago, few months later we moved all repos to our Ubuntu
development server and last month or so I upgraded svn to 1.8, without
the possibility of a full dump/load because of my not working script
anymore. One shouldn't start with platform specific console scripting
anymore unless it's about really trivial stuff. It's to easy these
days to change platforms.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@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: How Big A Dump File Can Be Handled?
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Ben Reser
> Sent: Wednesday, 21 August 2013 12:12 PM
> On Tue Aug 20 16:44:08 2013, Geoff Field wrote:
> > I've seen some quite large dump files already - one got up
> > to about 28GB. The svnadmin 1.2.3 tool managed to cope with
> > that quite successfully. Right now, our largest repository
> > (some 19,000 revisions with many files, including
> > installation packages) is dumping. In the 5300 range of
> > revisions, the dump file has just passed 9GB.
Overall, it got to about 29GB. Dump and load worked fine, although they got a bit slow towards the end. (In fact, I delayed sending this until it had actually finished.)
> Shouldn't be a problem within the limits of the OS and filesystem.
I've just realised that my concern was based on a power-of-2 limitation that means that a 32-bit signed integer would roll over at the 2GB mark, with an unsigned roll-over at 4GB. It's possible the Windows Server 2003 file system might have started to complain when it ran out of block indices/counters or some such, but there's no reason a 32GB+ file won't work if 4.1GB or more works.
> However, I'd say why are you bothering to produce dump files?
> Why not simply pipe the output of your dump command to a
> load command, e.g.
>
> svnadmin create newrepo
> svnadmin dump --incremental oldrepo | svnadmin load newrepo
I've been working in Windoze too long - I failed to think of that option. I'll use that for the rest of the repositories (about 19 remain to be done). Thank you for that application of the clue-by-four. You've made the rest of my task a lot easier.
I really should have done it all using a scripting language of some sort, too. I've told myself it's really too close to the end of the process to think of *that* change now, except I've just managed to quickly throw together a batch file to do the job. I could probably have done it in python or some other scripting language, but batch files are quick and easy. Again, thanks Ben for the prompt to use my head a bit better (even though you didn't explicitly suggest this aspect).
CopyBDBToFSFS.bat:
rem Create a new repository - using the OLD format just in case we need to switch back to the old server
"C:\Program Files\Subversion\bin\svnadmin.exe" create "%1_FSFS"
rem Copy the data from the old repository to the new one
"C:\Program Files\Subversion\bin\svnadmin.exe" dump --incremental "%1" | "C:\Program Files\Subversion\bin\svnadmin.exe" load "%1_FSFS"
rem Change the names to make the new repository accessible using the existing authentication and URLs and the old one accessible for emergency use.
ren "%1" "%1_BDB"
ren "%1_FSFS" "%1"
rem Check the new repository with the current tools to confirm it's OK.
svnadmin verify "%1"
Note that we have the old version 1.2.3 server software installed at the C:\Program Files\Subversion location, and later versions are stored under other locations, with the path set to point to the new version. I'm creating the new repositories with the old version for those (hopefully rare) occasions when we need to switch back to the old server version.
> You'll need space for two repos but that should be less than
> the space the dump file will take.
We're keeping the old repos anyway, just in case. We're an automotive parts company with support requirements for some quite old versions, so we can't afford to throw away too much history. Even though it's a RAID system (using Very Expensive disk drives, so it's actually a RAVED system), there's lots of space available on the drive where the repositories live.
> I included the
> --incremental option above because there's no reason to
> describe the full tree for every revision when you're doing a
> dump/load cycle.
That makes sense.
> You can save space with --deltas if you
> really want the dump files, but at the cost of extra CPU time.
> If you're just piping to load the CPU to calculate the delta
> isn't worth it since you're not saving the dump file.
I agree. The server's not particularly new, so if I can save on processor time that's a good thing. I'm discarding/reusing the dump files anyway, since we're keeping the original repositories (and we have a separate backup system for the servers - I know it works too, because I've had to restore some of the BDB repositories from it).
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- 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: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Thomas Harold
> Sent: Friday, 23 August 2013 11:53 AM
> On 8/22/2013 7:11 PM, Geoff Field wrote:
> Most restores for us took about 5-10 minutes, a few of our
> larger repos took a few hours.
I was doing this all in the background via remote login to our SVN server, so I didn't monitor times. Some of our repos only took seconds because there wasn't much to load. The ones that involved more people and more changes took up to somewhere on the order of an hour or so. Usually, I'd just set it going and do other work while occasionally glancing at the remote desktop session to see if it had finished the current step.
> Since we use svn+ssh, repository permissions matter a bit more for us.
We only allow https access and we only have a few users now, so monitoring and controlling access during the changeover was easy.
Besides, nobody was ABLE to access the BDB repositories because the more recent server builds that you can download don't include the BDB module. Simply stopping the old server software was enough to kill all access to the BDB repositories in our case.
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- 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: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
Posted by Thomas Harold <th...@nybeta.com>.
On 8/22/2013 7:11 PM, Geoff Field wrote:
>> 6. Create the repository in svn 1.8.
>
> I'm sure there's an "upgrade" command that would do it all in-place.
>
>> 7. Strip permissions on the repository back down to 700, owned by
>> root:root while we reload the data.
>
> While, or before?
Step 6 created the repos in our system with writable permissions, so we
had to make sure nobody could commit to the repo while we loaded back i
the dump file in step 9.
Most restores for us took about 5-10 minutes, a few of our larger repos
took a few hours.
>
> On your OS, is there a way to read the permissions first?
>
Mmm, we could have used "stat -c 0%a /path/to/file", but with the script
to set our permissions, and because we structure our repos as
"category-reponame", we can set permissions across entire categories
easily with the script.
Since we use svn+ssh, repository permissions matter a bit more for us.
RE: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
Posted by Geoff Field <Ge...@aapl.com.au>.
Hi Thomas,
> From: Thomas Harold
> Sent: Friday, 23 August 2013 1:25 AM
> On 8/21/2013 7:13 PM, Geoff Field wrote:
> > I'm keeping the
> > original BDB repositories, with read-only permissions.
> > If I really have the need, I can restart Apache 2 with SVN
> > 1.2.3 and
> > go back to the original repositories....
>
> When we did our 1.6 to 1.8 upgrade a few weeks ago, I used
> the following steps (ours was an in-place upgrade, so a bit
> of extra checking was added):
>
> 0. Back everything up, twice.
Our servers have nightly backups that I know to work (from experience). I also didn't get rid of the originals (as stated).
> 1. Check the version of the repository to see whether it is
> already 1.8
I *knew* that all of our repositories were in the 1.2 format. That's the only version we had for years on end.
...
> 2. Strip permissions on the original repo down to read-only.
I didn't bother with that, since I didn't do any write operations on the repos (other than changing the names. However, I *did* change the repo access permissions in the authz file.
> 3. Ran "svnadmin verify" on the original repository.
Probably something I should have done, but luckily I ended up with no obvious failures in the dumps.
> 4. Do the "svnadmin dump", piping the output into gzip -5
> (moderate compression).
If you're removing the old repo, I suppose it makes sense to keep the dump file. Compression would make it less onerous in storage terms.
> 5. Remove the old repository directory.
I agree with what the script echoes - "dangerous"
> 6. Create the repository in svn 1.8.
I'm sure there's an "upgrade" command that would do it all in-place.
> 7. Strip permissions on the repository back down to 700,
> owned by root:root while we reload the data.
While, or before?
> 8. Fix the db/fsfs.conf file to take advantage of new features.
>
> Note: Make sure you understand what enable-dir-deltification,
> enable-props-deltification and enable-rep-sharing do. Some
> of these are not turned on in SVN 1.8 by default.
There are features we're very unlikely to need at this stage in our company existence.
> 9. Load the repository back from the dump file.
At last!
> 10. Run "svnadmin pack" to pack revs/revprops files (saves on inodes).
Makes sense
> 11. Run "svnadmin verify".
Always a good thing to do.
> 12. Restore original permissions.
Fair enough.
> Note: I have a custom script that I can run to set
> permissions correctly on our repository directories. I never
> set file system permissions by hand on the repositories, I
> always update the script and then use that.
> (With a few hundred repositories, I have to be organized and rely on
> scripts.)
On your OS, is there a way to read the permissions first?
> 13. Back everything up again, twice.
You're not paranoid if they really *are* out to get you... ;-)
> All-in-all, it took us a few days to convert 110GB of
> repositories (mostly in 1.6 format), but the resulting size
> was only 95GB and far fewer files (due to revprops packing in
> 1.8). Our nightly backup window went from about 3 hours,
> down to 30 minutes from using "svnadmin hotcopy
> --incremental". When then use rdiff-backup to push the
> hotcopy directory to a backup server.
I've just surprised myself by checking the file system properties. After the BDB->FSFS conversion, we now have 164 repositories, totallying 312GB on the disk. That's a LOT of backup space requirement. Luckily for me, that's all handled by our IT department and is done on their SAN via an automatic utility.
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- 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: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
Posted by Thomas Harold <th...@nybeta.com>.
On 8/21/2013 7:13 PM, Geoff Field wrote:> I'm keeping the original BDB
repositories, with read-only permissions.
> If I really have the need, I can restart Apache 2 with SVN 1.2.3 and
> go back to the original repositories. Otherwise, I also have the
> option of re-running my batch file (modifying it if absolutely
> required). On top of that, there are bunches of files on another
> server that give us at least the latest state of the projects. The
> dump files in this case are not really as useful as the data itself.
> Regards, Geoff
>
When we did our 1.6 to 1.8 upgrade a few weeks ago, I used the following
steps (ours was an in-place upgrade, so a bit of extra checking was added):
0. Back everything up, twice.
1. Check the version of the repository to see whether it is already 1.8
BASE='/var/svn/'
TARGET='/backup/svndump/'
DIR='somereponame'
SVNADMIN=/path/to/svnadmin
REPOFMT=`grep '^[123456]$' ${BASE}${DIR}/db/format`
echo "FSVS database format is $REPOFMT"
if [ $REPOFMT -ge 6 ]; then
echo "Format >= 6, not upgrading."
continue
fi
Note: That was a quick-n-dirty check that was valid for our
configuration. To be truly correct, you need to verify:
reponame/format
reponame/db/fs-type
reponame/db/format
2. Strip permissions on the original repo down to read-only.
3. Ran "svnadmin verify" on the original repository.
echo "Run svnadmin verify..."
$SVNADMIN verify --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo "svnadmin verify failed with status: $status"
continue
else
echo "svnadmin verify succeeded"
fi
4. Do the "svnadmin dump", piping the output into gzip -5 (moderate
compression).
echo "svnadmin dump..."
$SVNADMIN dump --quiet ${BASE}${DIR} | gzip -5 --rsyncable >
${TARGET}${DIR}.dump.gz
status=$?
if [ $status -ne 0 ]; then
echo "svnadmin dump failed with status: $status"
continue
fi
5. Remove the old repository directory.
echo "Remove old repository (dangerous)"
rm -rf ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo "remove failed with status: $status"
continue
fi
6. Create the repository in svn 1.8.
echo "Recreate repository with svnadmin"
$SVNADMIN create ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo "svnadmin create failed with status: $status"
continue
fi
7. Strip permissions on the repository back down to 700, owned by
root:root while we reload the data.
8. Fix the db/fsfs.conf file to take advantage of new features.
Note: Make sure you understand what enable-dir-deltification,
enable-props-deltification and enable-rep-sharing do. Some of these are
not turned on in SVN 1.8 by default.
echo "Fix db/fsfs.conf file"
sed 's/^[#[:space:]]*enable-rep-sharing =
false[#[:space:]]*$/enable-rep-sharing =
true/g;s/^[#[:space:]]*enable-dir-deltificati
on = false[#[:space:]]*$/enable-dir-deltification =
true/g;s/^[#[:space:]]*enable-props-deltification =
false[#[:space:]]*$/enable-p
rops-deltification = true/g' --in-place=.bkp ${BASE}${DIR}/db/fsfs.conf
status=$?
if [ $status -ne 0 ]; then
echo "sed adjustment of db/fsfs.conf failed with status: $status"
continue
fi
9. Load the repository back from the dump file.
echo "svnadmin load..."
gzip -c -d ${TARGET}${DIR}.dump.gz | $SVNADMIN load --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo "svnadmin load failed with status: $status"
continue
fi
10. Run "svnadmin pack" to pack revs/revprops files (saves on inodes).
echo "svnadmin pack..."
$SVNADMIN pack --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo "svnadmin pack failed with status: $status"
continue
fi
11. Run "svnadmin verify".
echo "Run svnadmin verify..."
$SVNADMIN verify --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo "svnadmin verify failed with status: $status"
continue
else
echo "svnadmin verify succeeded"
fi
12. Restore original permissions.
Note: I have a custom script that I can run to set permissions correctly
on our repository directories. I never set file system permissions by
hand on the repositories, I always update the script and then use that.
(With a few hundred repositories, I have to be organized and rely on
scripts.)
13. Back everything up again, twice.
All-in-all, it took us a few days to convert 110GB of repositories
(mostly in 1.6 format), but the resulting size was only 95GB and far
fewer files (due to revprops packing in 1.8). Our nightly backup window
went from about 3 hours, down to 30 minutes from using "svnadmin hotcopy
--incremental". When then use rdiff-backup to push the hotcopy
directory to a backup server.
RE: How Big A Dump File Can Be Handled?
Posted by Geoff Field <Ge...@aapl.com.au>.
________________________________
From: Nico Kadel-Garcia
Sent: Thursday, 22 August 2013 8:10 AM
I would never do a transfer like this without a copy of the dumpfile available, for reference. The pain of having to re-run the dump later, especially if there are any bugs in the "svnadmin load" configuration, normally justifies keeping the dump around until well after the migraiton is completed.
Hi Nico,
I'm keeping the original BDB repositories, with read-only permissions. If I really have the need, I can restart Apache 2 with SVN 1.2.3 and go back to the original repositories. Otherwise, I also have the option of re-running my batch file (modifying it if absolutely required).
On top of that, there are bunches of files on another server that give us at least the latest state of the projects.
The dump files in this case are not really as useful as the data itself.
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department:
- 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: How Big A Dump File Can Be Handled?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
I would never do a transfer like this without a copy of the dumpfile
available, for reference. The pain of having to re-run the dump later,
especially if there are any bugs in the "svnadmin load" configuration,
normally justifies keeping the dump around until well after the migraiton
is completed.
On Tue, Aug 20, 2013 at 10:11 PM, Ben Reser <be...@reser.org> wrote:
> On Tue Aug 20 16:44:08 2013, Geoff Field wrote:
> > I've seen some quite large dump files already - one got up to about
> 28GB. The svnadmin 1.2.3 tool managed to cope with that quite
> successfully. Right now, our largest repository (some 19,000 revisions
> with many files, including installation packages) is dumping. In the 5300
> range of revisions, the dump file has just passed 9GB.
>
> Shouldn't be a problem within the limits of the OS and filesystem.
> However, I'd say why are you bothering to produce dump files? Why not
> simply pipe the output of your dump command to a load command, e.g.
>
> svnadmin create newrepo
> svnadmin dump --incremental oldrepo | svnadmin load newrepo
>
> You'll need space for two repos but that should be less than the space
> the dump file will take. I included the --incremental option above
> because there's no reason to describe the full tree for every revision
> when you're doing a dump/load cycle. You can save space with --deltas
> if you really want the dump files, but at the cost of extra CPU time.
> If you're just piping to load the CPU to calculate the delta isn't
> worth it since you're not saving the dump file.
>
Re: How Big A Dump File Can Be Handled?
Posted by Ben Reser <be...@reser.org>.
On Tue Aug 20 16:44:08 2013, Geoff Field wrote:
> I've seen some quite large dump files already - one got up to about 28GB. The svnadmin 1.2.3 tool managed to cope with that quite successfully. Right now, our largest repository (some 19,000 revisions with many files, including installation packages) is dumping. In the 5300 range of revisions, the dump file has just passed 9GB.
Shouldn't be a problem within the limits of the OS and filesystem.
However, I'd say why are you bothering to produce dump files? Why not
simply pipe the output of your dump command to a load command, e.g.
svnadmin create newrepo
svnadmin dump --incremental oldrepo | svnadmin load newrepo
You'll need space for two repos but that should be less than the space
the dump file will take. I included the --incremental option above
because there's no reason to describe the full tree for every revision
when you're doing a dump/load cycle. You can save space with --deltas
if you really want the dump files, but at the cost of extra CPU time.
If you're just piping to load the CPU to calculate the delta isn't
worth it since you're not saving the dump file.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR
ME)
Posted by Geoff Field <Ge...@aapl.com.au>.
________________________________
From: Nico Kadel-Garcia
Sent: Friday, 16 August 2013 21:39 PM
To: Geoff Field
Cc: Philip Martin; users@subversion.apache.org
Subject: Re: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)
Get your legacy material off BDB and onto FSFS, ASAP. At least make sure you have *good* backups and are prepared to lose all that data if you don't. BDB has been, in my experience with much older versions of Subversion and with years of Linux application experience, prone to data corruption from unpredictable and unrecoverable userland events and even the slightest blip of the OS or hardware layer. It has also repeatedly proven impossible to upgrade existing data sets to new BDB releases in place. Subversion fortunately has a workable backup system to provide data transfers: I've seen BDB systems that did not.
Thanks for the opinion Nico. I'm in the middle of doing the translation now. As I said, though, we have about 100 repositories, most of them in BDB format, so it's no small task.
The servers are backed up nightly using IBM's Tivoli Storage Manager. I've had to recover repositories a few times using that tool, so I know it works for us.
BDB has never been my friend.
We've had a few corrupt repositories over the years. We got to the stage where we wrote an internal Wiki page on fixing corrupt repositories.
We had a colleague write an application to help with management of the repos. Unfortunately, he chose to create them in BDB format. That's why we have so many BDB repositories. Rather than recreate the build environment and rebuild the management application, I've edited the EXE file to replace the (DBCS) string that sets the format with spaces.
Geoff
On Fri, Aug 16, 2013 at 2:13 AM, Geoff Field wrote:
> From: Geoff Field
> Sent: Friday, 16 August 2013 11:56 AM
> Thanks to everybody for their patience with my issue. The
> root cause is not really solved, but at least I (and my
> colleagues) can get back to normal work patterns.
>
> I've finally managed to get the upgrade to Apache 2.2 and SVN
> server 1.6.9 running. As it turns out, my former colleagues
> had deliberately configured all the ports one up from the
> default (thus, SSL was running on port 444 instead of the
> default 443). Once I'd fixed this, Apache 2.2 started
> serving SVN via the default interfaces.
>
> With that, I can now run everything happily.
It seems I spoke too soon. It turns out that the updated SVN server 1.6.9 works for those few of our repositories that are in FSFS format. Unfortunately, our legacy repositories are almost all in BDB format and I'm loathe to touch them if I can avoid it.
Building SVN from source is not really a useful option, but we can do it (with a struggle) if we absolutely have to. Frankly, I'd rather convert all the repositories (and there are 100 all up, although some are in FSFS format already) than build the server code. Has anybody built a version that handles BDB in a DAV module?
> I have not deleted the Apache 2.0/SVN server 1.2.3
> configuration, so I should be able to switch back to that if
> needed. I suppose it's possible some repositories might
> become inaccessible to the earlier server due to the server
> upgrade, but I'm not particularly fussed about that.
We can swap back to the other version fairly easily if we have to, just by stopping Apache2.2 and starting Apache2 (or vice-versa).
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.
How Big A Dump File Can Be Handled?
Posted by Geoff Field <Ge...@aapl.com.au>.
Just a query out of curiosity:
I'm currently in the process of migrating all 74 of our BDB repositories to FSFS via a dump/create/load cycle.
I've seen some quite large dump files already - one got up to about 28GB. The svnadmin 1.2.3 tool managed to cope with that quite successfully. Right now, our largest repository (some 19,000 revisions with many files, including installation packages) is dumping. In the 5300 range of revisions, the dump file has just passed 9GB.
Am I going to run into problems, or is it open-ended? This probably comes down to the data type of the file index parameters/variables.
I guess I'll find out soon enough, as the dump churns away (and, if/when that succeeds, the subsequent load churns through).
Just in case any developer is on hand during my work day here in Australia, it might be nice to know. I'll let the list know if there's a crash during the process, too.
Regards,
Geoff
--
Apologies for the auto-generated legal boilerplate added by our IT department.
- 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 - SOLVED (FOR ME)
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
Get your legacy material off BDB and onto FSFS, ASAP. At least make sure
you have *good* backups and are prepared to lose all that data if you
don't. BDB has been, in my experience with much older versions of
Subversion and with years of Linux application experience, prone to data
corruption from unpredictable and unrecoverable userland events and even
the slightest blip of the OS or hardware layer. It has also repeatedly
proven impossible to upgrade existing data sets to new BDB releases in
place. Subversion fortunately has a workable backup system to provide data
transfers: I've seen BDB systems that did not.
BDB has never been my friend.
On Fri, Aug 16, 2013 at 2:13 AM, Geoff Field <Ge...@aapl.com.au>wrote:
> > From: Geoff Field
> > Sent: Friday, 16 August 2013 11:56 AM
> > Thanks to everybody for their patience with my issue. The
> > root cause is not really solved, but at least I (and my
> > colleagues) can get back to normal work patterns.
> >
> > I've finally managed to get the upgrade to Apache 2.2 and SVN
> > server 1.6.9 running. As it turns out, my former colleagues
> > had deliberately configured all the ports one up from the
> > default (thus, SSL was running on port 444 instead of the
> > default 443). Once I'd fixed this, Apache 2.2 started
> > serving SVN via the default interfaces.
> >
> > With that, I can now run everything happily.
>
> It seems I spoke too soon. It turns out that the updated SVN server 1.6.9
> works for those few of our repositories that are in FSFS format.
> Unfortunately, our legacy repositories are almost all in BDB format and
> I'm loathe to touch them if I can avoid it.
>
> Building SVN from source is not really a useful option, but we can do it
> (with a struggle) if we absolutely have to. Frankly, I'd rather convert
> all the repositories (and there are 100 all up, although some are in FSFS
> format already) than build the server code. Has anybody built a version
> that handles BDB in a DAV module?
>
> > I have not deleted the Apache 2.0/SVN server 1.2.3
> > configuration, so I should be able to switch back to that if
> > needed. I suppose it's possible some repositories might
> > become inaccessible to the earlier server due to the server
> > upgrade, but I'm not particularly fussed about that.
>
> We can swap back to the other version fairly easily if we have to, just by
> stopping Apache2.2 and starting Apache2 (or vice-versa).
>
> Regards,
>
> Geoff
>
> --
> Geoff Field
> Testing Coordinator, Work Health & Safety Rep, Chief Fire Warden, First
> Aider
> Australian Arrow Pty Ltd www.australianarrow.com.au
> 46 Lathams Rd, Carrum Downs, Vic, 3201, Australia
> phone (+61-3) 97850597, fax (+61-3) 9785 0583
> GYNET x-067-597
> - 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 - SOLVED (FOR
ME)
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Geoff Field
> Sent: Friday, 16 August 2013 11:56 AM
> Thanks to everybody for their patience with my issue. The
> root cause is not really solved, but at least I (and my
> colleagues) can get back to normal work patterns.
>
> I've finally managed to get the upgrade to Apache 2.2 and SVN
> server 1.6.9 running. As it turns out, my former colleagues
> had deliberately configured all the ports one up from the
> default (thus, SSL was running on port 444 instead of the
> default 443). Once I'd fixed this, Apache 2.2 started
> serving SVN via the default interfaces.
>
> With that, I can now run everything happily.
It seems I spoke too soon. It turns out that the updated SVN server 1.6.9 works for those few of our repositories that are in FSFS format. Unfortunately, our legacy repositories are almost all in BDB format and I'm loathe to touch them if I can avoid it.
Building SVN from source is not really a useful option, but we can do it (with a struggle) if we absolutely have to. Frankly, I'd rather convert all the repositories (and there are 100 all up, although some are in FSFS format already) than build the server code. Has anybody built a version that handles BDB in a DAV module?
> I have not deleted the Apache 2.0/SVN server 1.2.3
> configuration, so I should be able to switch back to that if
> needed. I suppose it's possible some repositories might
> become inaccessible to the earlier server due to the server
> upgrade, but I'm not particularly fussed about that.
We can swap back to the other version fairly easily if we have to, just by stopping Apache2.2 and starting Apache2 (or vice-versa).
Regards,
Geoff
--
Geoff Field
Testing Coordinator, Work Health & Safety Rep, Chief Fire Warden, First Aider
Australian Arrow Pty Ltd www.australianarrow.com.au
46 Lathams Rd, Carrum Downs, Vic, 3201, Australia
phone (+61-3) 97850597, fax (+61-3) 9785 0583
GYNET x-067-597
- 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 - SOLVED (FOR
ME)
Posted by Geoff Field <Ge...@aapl.com.au>.
Thanks to everybody for their patience with my issue. The root cause is not really solved, but at least I (and my colleagues) can get back to normal work patterns.
I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9 running. As it turns out, my former colleagues had deliberately configured all the ports one up from the default (thus, SSL was running on port 444 instead of the default 443). Once I'd fixed this, Apache 2.2 started serving SVN via the default interfaces.
With that, I can now run everything happily.
I have not deleted the Apache 2.0/SVN server 1.2.3 configuration, so I should be able to switch back to that if needed. I suppose it's possible some repositories might become inaccessible to the earlier server due to the server upgrade, but I'm not particularly fussed about that.
Regards,
Geoff
--
Geoff Field
- 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
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Philip Martin
> Sent: Thursday, 15 August 2013 19:02 PM
> Geoff Field writes:
> > I've just commented out the "AuthzSVNAccessFile" line and have done
> > the following:
This time, I changed the "AuthType" line to "AuthType None" for the Subversion location. Similar test (but with fewer typos this time).
C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
A SVN_Test\test7.txt
A SVN_Test\test.txt
Checked out revision 898.
C:\>cd SVN_Test
C:\SVN_Test>copy test.txt test9.txt
1 file(s) copied.
C:\SVN_Test>svn add test9.txt
A test9.txt
C:\SVN_Test>svn ci test9.txt --message "test9"
Adding test9.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\SVN_Test\test9.txt' is out of date
svn: E175005: File 'test9.txt' already exists
> > C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
> > Adding test6.txt
> > svn: E155011: Commit failed (details follow):
> > svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date
> > svn: E175005: File 'test6.txt' already exists
Same error report persisting.
> > 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "CHECKOUT
> > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> > 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "HEAD
> > /Subversion/Playground/trunk/test6.txt HTTP/1.1" 401 -
> > 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE
> >
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2
> > HTTP/1.1" 401 580
> > 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE
> >
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2
> > HTTP/1.1" 401 580
> > 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "DELETE
> >
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2
> > HTTP/1.1" 204 -
>
> That still shows "401 unauthorized" which is odd if you are
> not using Authz. Do you have some other authz beyond
> AuthzSVNAccessFile?
It could be the SSL layer. The location section does contain the following line:
SSLRequireSSL
Still showing:
...
0.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:24 +1000] "CHECKOUT /Subversion/Playground/!svn/ver/898/trunk HTTP/1.1" 201 439
10.63.36.64 - - [16/Aug/2013:09:39:25 +1000] "HEAD /Subversion/Playground/trunk/test9.txt HTTP/1.1" 401 -
10.63.36.64 - - [16/Aug/2013:09:39:26 +1000] "DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1" 401 580
10.63.36.64 - - [16/Aug/2013:09:39:27 +1000] "DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:27 +1000] "DELETE /Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1" 204 -
> The 1.2.3 client simply shows that with neon we don't send HEAD.
>
> > Again, the error log did not change.
>
> You may get more information if you add
>
> LogLevel debug
I did that, too. I'll email the full results privately, as the 3000-odd lines resulting from this set of transactions is a bit too big for a group email. The final sections of the error log say this, though:
...
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1490): +-------------------------------------------------------------------------+
[Fri Aug 16 09:39:25 2013] [info] Subsequent (No.11) HTTPS request received for child 249 (server aapleng1.aapl.com.au:443)
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 bytes expected to read on BIO#1114588 [mem: 121bae8]
[Fri Aug 16 09:39:25 2013] [info] Connection to child 248 established (server aapleng1.aapl.com.au:443, client 10.63.36.64)
[Fri Aug 16 09:39:25 2013] [info] (70014)End of file found: SSL input filter read failed.
[Fri Aug 16 09:39:25 2013] [info] Seeding PRNG with 136 bytes of entropy
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: SSL negotiation finished successfully
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1776): OpenSSL: Handshake: start
[Fri Aug 16 09:39:25 2013] [info] Connection to child 249 closed with standard shutdown(server aapleng1.aapl.com.au:443, client 10.63.36.64)
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1784): OpenSSL: Loop: before/accept initialization
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1512): OpenSSL: read 11/11 bytes from BIO#112df18 [mem: 52345e0] (BIO dump follows)
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1459): +-------------------------------------------------------------------------+
...
[Fri Aug 16 09:39:27 2013] [info] Subsequent (No.2) HTTPS request received for child 248 (server aapleng1.aapl.com.au:443)
[Fri Aug 16 09:39:27 2013] [info] [client 10.63.36.64] Access granted: 'AAPL\\gf' DELETE Playground:
[Fri Aug 16 09:39:27 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 bytes expected to read on BIO#112df18 [mem: 52345e0]
[Fri Aug 16 09:39:27 2013] [info] (70014)End of file found: SSL input filter read failed.
[Fri Aug 16 09:39:27 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: SSL negotiation finished successfully
[Fri Aug 16 09:39:27 2013] [info] Connection to child 248 closed with standard shutdown(server aapleng1.aapl.com.au:443, client 10.63.36.64)
Other parts of ths log contain lots of "read 5/5 bytes". It looks to me like a corner case with the last part of a fragmented packet.
Thanks again for any time and attention you feel fit to devote to this.
I'm still working as a background task to update the server. Having problems getting SVN to respond from Apache 2.2. (I know that almost everybody else in the world is running Apache 2.2 quite happily with SVN, so it's something I've done - more reading required...)
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
Posted by Philip Martin <ph...@wandisco.com>.
Geoff Field <Ge...@aapl.com.au> writes:
> I've just commented out the "AuthzSVNAccessFile" line and have done
> the following:
> C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
> Adding test6.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date
> svn: E175005: File 'test6.txt' already exists
> 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "HEAD /Subversion/Playground/trunk/test6.txt HTTP/1.1" 401 -
> 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 401 580
> 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 401 580
> 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 204 -
That still shows "401 unauthorized" which is odd if you are not using
Authz. Do you have some other authz beyond AuthzSVNAccessFile?
The 1.2.3 client simply shows that with neon we don't send HEAD.
> Again, the error log did not change.
You may get more information if you add
LogLevel debug
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Philip Martin
> Sent: Wednesday, 14 August 2013 9:59 AM
> 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:
> >
> > <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've just commented out the "AuthzSVNAccessFile" line and have done the following:
C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
A SVN_Test\test.txt
Checked out revision 897.
C:\>cd SVN_Test
C:\SVN_Test>copy test.txt test6.txt
1 file(s) copied.
C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
svn: E200009: Commit failed (details follow):
svn: E200009: 'C:\SVN_Test\test6.txt' is not under version control
C:\SVN_Test>svn add test6.txt
A test6.txt
C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
Adding test6.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date
svn: E175005: File 'test6.txt' already exists
C:\SVN_Test>
That first ci is a procedural error, but I left it in for completeness.
The Apache error log DID NOT change at all. No new entries were added by the test. The new Apache access log entries are as follows:
10.63.36.69 - - [15/Aug/2013:10:31:10 +1000] "GET / HTTP/1.1" 200 28508
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 201
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 97
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 207 481
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/bc/897/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/bc/897/trunk HTTP/1.1" 207 343
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 201
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 97
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 207 481
10.63.36.64 - - [15/Aug/2013:10:32:32 +1000] "PROPFIND /Subversion/Playground/!svn/bc/897 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:32 +1000] "PROPFIND /Subversion/Playground/!svn/bc/897 HTTP/1.1" 207 1297
10.63.36.64 - - [15/Aug/2013:10:32:32 +1000] "REPORT /Subversion/Playground/!svn/vcc/default HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:32 +1000] "REPORT /Subversion/Playground/!svn/vcc/default HTTP/1.1" 200 1417
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 201
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 97
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "MKACTIVITY /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "MKACTIVITY /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 201 421
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 422
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "CHECKOUT /Subversion/Playground/!svn/vcc/default HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "CHECKOUT /Subversion/Playground/!svn/vcc/default HTTP/1.1" 201 437
10.63.36.64 - - [15/Aug/2013:10:33:20 +1000] "PROPPATCH /Subversion/Playground/!svn/wbl/fe51daff-f5fc-d84f-ada1-17b5395050b2/897 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:20 +1000] "PROPPATCH /Subversion/Playground/!svn/wbl/fe51daff-f5fc-d84f-ada1-17b5395050b2/897 HTTP/1.1" 207 475
10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "HEAD /Subversion/Playground/trunk/test6.txt HTTP/1.1" 401 -
10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "DELETE /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 HTTP/1.1" 204 -
For comparison, I did the same test on a machine running a 1.2.3 client (actually the server):
C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
Authentication realm: <https://aapleng1:443> Subversion repositories
Password for 'AAPL\gf': ********
A \SVN_Test\test.txt
Checked out revision 897.
C:\>cd \SVN_Test
C:\SVN_Test>copy test.txt test7.txt
1 file(s) copied.
C:\SVN_Test>svn add test7.txt
A test7.txt
C:\SVN_Test>svn ci test7.txt -message "Test 1.7 checkin"
svn: Commit failed (details follow):
svn: 'C:/SVN_Test/Test 1.7 checkin' is not under version control
C:\SVN_Test>svn ci test7.txt --message "Test 1.7 checkin"
Adding test7.txt
Transmitting file data .
Committed revision 898.
C:\SVN_Test>
Again, a slight typographical error there, but it worked in the end. The Apache access log had these lines added:
10.63.34.14 - - [15/Aug/2013:10:38:18 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.34.14 - - [15/Aug/2013:10:38:18 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 207 481
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 207 481
10.63.34.14 - - [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 481
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/bc/897/trunk HTTP/1.1" 207 724
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.34.14 - - [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/!svn/bln/897 HTTP/1.1" 207 481
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:38:24 +1000] "REPORT /Subversion/Playground/!svn/vcc/default HTTP/1.1" 200 1417
10.63.34.14 - - [15/Aug/2013:10:39:35 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "OPTIONS /Subversion/Playground/trunk HTTP/1.1" 200 201
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "MKACTIVITY /Subversion/Playground/!svn/act/b00c7807-8fb6-f341-b055-21b6d9fd08ee HTTP/1.1" 201 421
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 464
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "PROPFIND /Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "CHECKOUT /Subversion/Playground/!svn/bln/897 HTTP/1.1" 201 437
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "PROPPATCH /Subversion/Playground/!svn/wbl/b00c7807-8fb6-f341-b055-21b6d9fd08ee/897 HTTP/1.1" 207 368
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "PROPFIND /Subversion/Playground/trunk HTTP/1.1" 207 422
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "CHECKOUT /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:36 +1000] "PROPFIND /Subversion/Playground/trunk/test7.txt HTTP/1.1" 404 414
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:38 +1000] "PUT /Subversion/Playground/!svn/wrk/b00c7807-8fb6-f341-b055-21b6d9fd08ee/trunk/test7.txt HTTP/1.1" 201 437
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:38 +1000] "MERGE /Subversion/Playground/trunk HTTP/1.1" 200 1065
10.63.34.14 - AAPL\\gf [15/Aug/2013:10:39:38 +1000] "DELETE /Subversion/Playground/!svn/act/b00c7807-8fb6-f341-b055-21b6d9fd08ee HTTP/1.1" 204 -
Again, the error log did not change.
> 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.
Probably. Due largely to my current position on the learning curve, I'm still struggling to get Apache updated correctly. I suspect I'll have to update the SVN server software at the same time. A previous colleague had both running separately - the old version on port 80 and the new on port 81 - but I'm not entirely clear on how it was working (or even IF it was working).
Thanks again for your patience and time (and sorry for the long post).
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
Posted by Philip Martin <ph...@wandisco.com>.
Geoff Field <Ge...@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
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Philip Martin
> Sent: Tuesday, 13 August 2013 19:59 PM
> Geoff Field <Ge...@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
Posted by Philip Martin <ph...@wandisco.com>.
Geoff Field <Ge...@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: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Geoff Field <Ge...@aapl.com.au>.
> -----Original Message-----
> From: Philip Martin
> Sent: Monday, 12 August 2013 18:57 PM
> Geoff Field writes:
> > Here's a log of a trial I have just done with a relatively
> fresh repository:
> >
> > C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
> > A SVN_Test\test.txt
> > Checked out revision 897.
> >
> > C:\>cd SVN_Test
> >
> > C:\SVN_Test>dir
> > Volume in drive C is OSDisk
> > Volume Serial Number is E49F-06D7
> >
> > Directory of C:\SVN_Test
> >
> > 12/08/2013 09:54 AM <DIR> .
> > 12/08/2013 09:54 AM <DIR> ..
> > 12/08/2013 09:54 AM 20 test.txt
> > 1 File(s) 20 bytes
> > 2 Dir(s) 160,268,779,520 bytes free
> >
> > C:\SVN_Test>copy test.txt test2.txt
> > 1 file(s) copied.
> >
> > C:\SVN_Test>svn add test2.txt
> > A test2.txt
> >
> > C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
> > Adding test2.txt
> > svn: E155011: Commit failed (details follow):
> > svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
> > svn: E175005: File 'test2.txt' already exists
>
> 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.
Attached for general amusement and delectation is the relevant portion of our Apache access log for a repeat test I did this morning (Australian Eastern Standard Time). The testing did not touch our Apache error log.
Regards,
Geoff
--
Sorry about the automatic legal disclaimer:
- 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
Posted by Philip Martin <ph...@wandisco.com>.
Geoff Field <Ge...@aapl.com.au> writes:
> Here's a log of a trial I have just done with a relatively fresh repository:
>
> C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
> A SVN_Test\test.txt
> Checked out revision 897.
>
> C:\>cd SVN_Test
>
> C:\SVN_Test>dir
> Volume in drive C is OSDisk
> Volume Serial Number is E49F-06D7
>
> Directory of C:\SVN_Test
>
> 12/08/2013 09:54 AM <DIR> .
> 12/08/2013 09:54 AM <DIR> ..
> 12/08/2013 09:54 AM 20 test.txt
> 1 File(s) 20 bytes
> 2 Dir(s) 160,268,779,520 bytes free
>
> C:\SVN_Test>copy test.txt test2.txt
> 1 file(s) copied.
>
> C:\SVN_Test>svn add test2.txt
> A test2.txt
>
> C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
> Adding test2.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
> svn: E175005: File 'test2.txt' already exists
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?
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Philip Martin
> Sent: Friday, 9 August 2013 18:10 PM
> Geoff Field <Ge...@aapl.com.au> writes:
>
> > What about the Commit New Files error? Will this be fixed
> with 1.8.2,
> > do you think?
>
> I don't know how to reproduce it. You said:
>
> Second issue: When committing new files, we get the message
> that one of
> them 'already exists'. I've found as a workaround that
> doing a clean
> checkout to a NEW directory, then copying everything across
> and running
> a commit will work - once.
>
> but if I were to attempt to reproduce it I would do
>
> svnadmin create repo
> svn co http://localhost/repo wc
> cp /bin/true wc/foo # error message was for a binary file
> svn add wc/foo
> svn ci -mm wc
>
> but that works. That's no surprise because what I have done
> is essentially what you say is a "workaround". Until you can
> come up with a better description of how to reproduce the
> problem not much can be done.
Hello Philip,
Sometimes the workaround works, sometimes it doesn't.
Here's a log of a trial I have just done with a relatively fresh repository:
C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
A SVN_Test\test.txt
Checked out revision 897.
C:\>cd SVN_Test
C:\SVN_Test>dir
Volume in drive C is OSDisk
Volume Serial Number is E49F-06D7
Directory of C:\SVN_Test
12/08/2013 09:54 AM <DIR> .
12/08/2013 09:54 AM <DIR> ..
12/08/2013 09:54 AM 20 test.txt
1 File(s) 20 bytes
2 Dir(s) 160,268,779,520 bytes free
C:\SVN_Test>copy test.txt test2.txt
1 file(s) copied.
C:\SVN_Test>svn add test2.txt
A test2.txt
C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
Adding test2.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
svn: E175005: File 'test2.txt' already exists
C:\SVN_Test>svn --version
svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
C:\SVN_Test>
Again, server version is 1.2 (yes, yes, I will update this at some stage in the near future, but apparently I also have to update Apache, which adds an extra layer of nuisance).
This was the first time this repository had been touched since 2009.
"test.txt" is a standard ASCII text file containing the sentence "A quick test file." with one carriage return.
I hope this helps.
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
Posted by Philip Martin <ph...@wandisco.com>.
Geoff Field <Ge...@aapl.com.au> writes:
> What about the Commit New Files error? Will this be fixed with 1.8.2,
> do you think?
I don't know how to reproduce it. You said:
Second issue: When committing new files, we get the message that one of
them 'already exists'. I've found as a workaround that doing a clean
checkout to a NEW directory, then copying everything across and running
a commit will work - once.
but if I were to attempt to reproduce it I would do
svnadmin create repo
svn co http://localhost/repo wc
cp /bin/true wc/foo # error message was for a binary file
svn add wc/foo
svn ci -mm wc
but that works. That's no surprise because what I have done is
essentially what you say is a "workaround". Until you can come up with
a better description of how to reproduce the problem not much can be
done.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Geoff Field
> Sent: Tuesday, 6 August 2013 9:33 AM
> > From: lieven.govaerts
> > On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin
> > <ph...@wandisco.com> wrote:
> > > Philip Martin <ph...@wandisco.com> writes:
> > >
> > >> Lieven Govaerts <lg...@apache.org> writes:
> > >>
> > >>>> C:\Customer>svn log -v ./
> > >>>> svn: E175002: Unexpected HTTP status 501 'Method Not
> > Implemented'
> > >>>> on '/Subversio
> >
> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
> > >>>>
> > >>>> svn: E200007: Additional errors:
> > >>>> svn: E200007: The requested report is unknown.
> >
> > Geoff, can you log an issue in our issue tracker with reference to
> > this mail thread?
> > http://subversion.tigris.org/issue-tracker.html
>
> Done. Issue #4404 has been logged, specifically for the
> first part of the issue. Personally, I don't like reporting
> two issues in one report, so I'll leave the other issue
> separate - at least until I'm asked to lodge that as well.
> At least the original issue report references some of the
> many mailing list discussions about it.
So does the patch fix both issues?
> ...
> > >> That's easy to reproduce using 1.1.4 mod_dav_svn:
> ...
> > Can you test if attached patch fixes this issue?
What about the Commit New Files error? Will this be fixed with 1.8.2, do you think?
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
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: lieven.govaerts
> On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin
> <ph...@wandisco.com> wrote:
> > Philip Martin <ph...@wandisco.com> writes:
> >
> >> Lieven Govaerts <lg...@apache.org> writes:
> >>
> >>>> C:\Customer>svn log -v ./
> >>>> svn: E175002: Unexpected HTTP status 501 'Method Not
> Implemented'
> >>>> on '/Subversio
> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
> >>>>
> >>>> svn: E200007: Additional errors:
> >>>> svn: E200007: The requested report is unknown.
>
> Geoff, can you log an issue in our issue tracker with
> reference to this mail thread?
> http://subversion.tigris.org/issue-tracker.html
Done. Issue #4404 has been logged, specifically for the first part of the issue. Personally, I don't like reporting two issues in one report, so I'll leave the other issue separate - at least until I'm asked to lodge that as well. At least the original issue report references some of the many mailing list discussions about it.
> >>> For this part of your issue, I'm interested in seeing a network
> >>> trace (wireshark, fiddler) between your client and server.
Thanks Philip.
...
> >> That's easy to reproduce using 1.1.4 mod_dav_svn:
...
> Can you test if attached patch fixes this issue?
And thanks for that Philip and Lieven.
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
Posted by Lieven Govaerts <lg...@apache.org>.
On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Lieven Govaerts <lg...@apache.org> writes:
>>
>>>> C:\Customer>svn log -v ./
>>>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio
>>>> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>>>>
>>>> svn: E200007: Additional errors:
>>>> svn: E200007: The requested report is unknown.
Geoff, can you log an issue in our issue tracker with reference to
this mail thread?
http://subversion.tigris.org/issue-tracker.html
>>> For this part of your issue, I'm interested in seeing a network trace
>>> (wireshark, fiddler) between your client and server. If that's
>>> possible for you, you can send them privately. Filter out any
>>> unrelated traffic and basic/digest authentication headers if possible.
>>
>> That's easy to reproduce using 1.1.4 mod_dav_svn:
>>
>> svnadmin create repo --compatible-version 1.1
>> svn mkdir -mm file://`pwd`/repo/A
>> svn co http://localhost/repo/A wc
>> svn log -v wc
>>
>> The client is sending a get-location-segments REPORT request which is
>> new in 1.5 and not supported by earlier mod_dav_svn.
>
> In libsvn_ra/ra-loader.c:svn_ra_get_location_segments the failure of the
> get-location-segments REPORT is expected to generate
> SVN_ERR_RA_NOT_IMPLEMENTED:
>
> if (err && (err->apr_err == SVN_ERR_RA_NOT_IMPLEMENTED))
> {
> svn_error_clear(err);
>
> /* Do it the slow way, using get-logs, for older servers. */
> err = svn_ra__location_segments_from_log(session, path,
> peg_revision, start_rev,
> end_rev, receiver,
> receiver_baton, pool);
> }
>
> but libsvn_ra_serf is returning SVN_ERR_RA_DAV_REQUEST_FAILED
>
> (gdb) p err[0]
> $3 = {apr_err = 175002, message = 0x7ffff6f85e7d "traced call",
> child = 0x7ffff7f300a0, pool = 0x7ffff7f30028,
> file = 0x7ffff5a4ab60 "../src/subversion/libsvn_ra_serf/getlocationsegments.c", line = 205}
> (gdb) p err[0].child[0]
> $4 = {apr_err = 175002,
> message = 0x7ffff7f300f0 "Unexpected HTTP status 501 'Method Not Implemented' on '/obj/repo/!svn/bc/1/A'\n", child = 0x7ffff7f30140, pool = 0x7ffff7f30028,
> file = 0x7ffff5a4edf0 "../src/subversion/libsvn_ra_serf/util.c", line = 2440}
Can you test if attached patch fixes this issue?
Lieven
>
> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Lieven Govaerts <lg...@apache.org> writes:
>
>>> C:\Customer>svn log -v ./
>>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio
>>> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>>>
>>> svn: E200007: Additional errors:
>>> svn: E200007: The requested report is unknown.
>>
>> For this part of your issue, I'm interested in seeing a network trace
>> (wireshark, fiddler) between your client and server. If that's
>> possible for you, you can send them privately. Filter out any
>> unrelated traffic and basic/digest authentication headers if possible.
>
> That's easy to reproduce using 1.1.4 mod_dav_svn:
>
> svnadmin create repo --compatible-version 1.1
> svn mkdir -mm file://`pwd`/repo/A
> svn co http://localhost/repo/A wc
> svn log -v wc
>
> The client is sending a get-location-segments REPORT request which is
> new in 1.5 and not supported by earlier mod_dav_svn.
In libsvn_ra/ra-loader.c:svn_ra_get_location_segments the failure of the
get-location-segments REPORT is expected to generate
SVN_ERR_RA_NOT_IMPLEMENTED:
if (err && (err->apr_err == SVN_ERR_RA_NOT_IMPLEMENTED))
{
svn_error_clear(err);
/* Do it the slow way, using get-logs, for older servers. */
err = svn_ra__location_segments_from_log(session, path,
peg_revision, start_rev,
end_rev, receiver,
receiver_baton, pool);
}
but libsvn_ra_serf is returning SVN_ERR_RA_DAV_REQUEST_FAILED
(gdb) p err[0]
$3 = {apr_err = 175002, message = 0x7ffff6f85e7d "traced call",
child = 0x7ffff7f300a0, pool = 0x7ffff7f30028,
file = 0x7ffff5a4ab60 "../src/subversion/libsvn_ra_serf/getlocationsegments.c", line = 205}
(gdb) p err[0].child[0]
$4 = {apr_err = 175002,
message = 0x7ffff7f300f0 "Unexpected HTTP status 501 'Method Not Implemented' on '/obj/repo/!svn/bc/1/A'\n", child = 0x7ffff7f30140, pool = 0x7ffff7f30028,
file = 0x7ffff5a4edf0 "../src/subversion/libsvn_ra_serf/util.c", line = 2440}
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Philip Martin <ph...@wandisco.com>.
Lieven Govaerts <lg...@apache.org> writes:
>> C:\Customer>svn log -v ./
>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio
>> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>>
>> svn: E200007: Additional errors:
>> svn: E200007: The requested report is unknown.
>
> For this part of your issue, I'm interested in seeing a network trace
> (wireshark, fiddler) between your client and server. If that's
> possible for you, you can send them privately. Filter out any
> unrelated traffic and basic/digest authentication headers if possible.
That's easy to reproduce using 1.1.4 mod_dav_svn:
svnadmin create repo --compatible-version 1.1
svn mkdir -mm file://`pwd`/repo/A
svn co http://localhost/repo/A wc
svn log -v wc
The client is sending a get-location-segments REPORT request which is
new in 1.5 and not supported by earlier mod_dav_svn.
OPTIONS /obj/repo/A HTTP/1.1
Host: localhost:8888
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Connection: keep-alive
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Content-Length: 131
<?xml version="1.0" encoding="utf-8"?><D:options xmlns:D="DAV:"><D:activity-collection-set></D:activity-collection-set></D:options>HTTP/1.1 200 OK
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
DAV: 1
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
MS-Author-Via: DAV
Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,CHECKOUT
Content-Length: 188
Keep-Alive: timeout=5
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:options-response xmlns:D="DAV:">
<D:activity-collection-set><D:href>/obj/repo/!svn/act/</D:href></D:activity-collection-set></D:options-response>
OPTIONS /obj/repo/A HTTP/1.1
Host: localhost:8888
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked
42
<?xml version="1.0" encoding="utf-8"?><D:options xmlns:D="DAV:" />
0
HTTP/1.1 200 OK
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
DAV: 1
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
MS-Author-Via: DAV
Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,CHECKOUT
Content-Length: 97
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:options-response xmlns:D="DAV:">
</D:options-response>
PROPFIND /obj/repo/A HTTP/1.1
Host: localhost:8888
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Depth: 0
Transfer-Encoding: chunked
12c
<?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><version-controlled-configuration xmlns="DAV:"/><resourcetype xmlns="DAV:"/><baseline-relative-path xmlns="http://subversion.tigris.org/xmlns/dav/"/><repository-uuid xmlns="http://subversion.tigris.org/xmlns/dav/"/></prop></propfind>
0
HTTP/1.1 207 Multi-Status
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
Content-Length: 678
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns1="http://subversion.tigris.org/xmlns/dav/" xmlns:ns0="DAV:">
<D:response xmlns:lp1="DAV:" xmlns:lp2="http://subversion.tigris.org/xmlns/dav/">
<D:href>/obj/repo/A/</D:href>
<D:propstat>
<D:prop>
<lp1:version-controlled-configuration><D:href>/obj/repo/!svn/vcc/default</D:href></lp1:version-controlled-configuration>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
<lp2:baseline-relative-path>A</lp2:baseline-relative-path>
<lp2:repository-uuid>71d71533-4707-4b1a-86cb-88d8fd12bffd</lp2:repository-uuid>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
PROPFIND /obj/repo/!svn/vcc/default HTTP/1.1
Host: localhost:8888
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Depth: 0
Label: 1
Transfer-Encoding: chunked
94
<?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><baseline-collection xmlns="DAV:"/><version-name xmlns="DAV:"/></prop></propfind>
0
HTTP/1.1 207 Multi-Status
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
Vary: Label
Content-Length: 449
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:">
<D:response xmlns:lp1="DAV:" xmlns:lp2="http://subversion.tigris.org/xmlns/dav/">
<D:href>/obj/repo/!svn/bln/1</D:href>
<D:propstat>
<D:prop>
<lp1:baseline-collection><D:href>/obj/repo/!svn/bc/1/</D:href></lp1:baseline-collection>
<lp1:version-name>1</lp1:version-name>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
REPORT /obj/repo/!svn/bc/1/A HTTP/1.1
Host: localhost:8888
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked
bd
<S:get-location-segments xmlns:S="svn:"><S:path></S:path><S:peg-revision>1</S:peg-revision><S:start-revision>1</S:start-revision><S:end-revision>0</S:end-revision></S:get-location-segments>
0
HTTP/1.1 501 Method Not Implemented
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
Content-Length: 228
Connection: close
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:error xmlns:D="DAV:" xmlns:m="http://apache.org/dav/xmlns" xmlns:C="svn:">
<C:error/>
<m:human-readable errcode="200007">
The requested report is unknown.
</m:human-readable>
</D:error>
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Posted by Lieven Govaerts <lg...@apache.org>.
Hi,
On Fri, Aug 2, 2013 at 2:06 AM, Geoff Field <Ge...@aapl.com.au> wrote:
> I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its command-line basis. Our server has been running 1.2 and has not been changed (apart from Windows updates) for a LONG time.
>
> (Yes, I know 1.2 is very old. However, we're an automotive company and changes to our tools can result in issues with customer approvals. Nonetheless, an upgrade is on the "to-do" list.)
A 1.8 client should have no problem communicating with any svn 1.x
server, so if that doesn't hold anymore for a 1.2 server then that's a
bug we want to fix.
> Having said that, there are now MANY people posting to the TSVN mailing list about these two issues.
>
> My platforms are 32-bit Windows 7 and Windows XP, but it has also been reported on 64-bit Windows.
>
>
> First issue: When doing a "Show Log", the client says it can't contact the server and asks if people (including us) want to go offline, then puts up an HTTP 501 error.
>
> Second issue: When committing new files, we get the message that one of them 'already exists'. I've found as a workaround that doing a clean checkout to a NEW directory, then copying everything across and running a commit will work - once.
>
>
> After discussions on the TSVN mailing list, I've run command-line versions of both, with the following results (edited to hide customer names):
>
> C:\Customer>svn log -v ./
> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio
> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>
> svn: E200007: Additional errors:
> svn: E200007: The requested report is unknown.
For this part of your issue, I'm interested in seeing a network trace
(wireshark, fiddler) between your client and server. If that's
possible for you, you can send them privately. Filter out any
unrelated traffic and basic/digest authentication headers if possible.
Lieven
> C:\Customer>svn commit ./ -m "Committing via command line"
> Adding (bin) DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDrlLimits.xlsx
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\Customer\DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDr
> lLimits.xlsx' is out of date
> svn: E175005: File 'OtherInputFiles/CustomerDrlLimits.xlsx' already exists
>
> C:\Customer>svn --version
> svn, version 1.8.1 (r1503906)
> compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows
>
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network protocol.
> - with Cyrus SASL authentication
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
> - handles 'http' scheme
> - handles 'https' scheme
>
> Regards,
>
> Geoff
>