RE: Trying to restore a corrupted repo

[Geoff Field]

[snip]
> First step is to *write lock* the old repository, to avoid 
> accumulating history on broken history.

Absolutely - and make sure the lock stays locked forever more.

> You will be *breaking history* due to the corrupted repo. You 
> should ideally create a new repo to do the repairs in, 
> explain the situation,and tell your user community to set 
> aside their working copies and make clean checkouts when 
> you're done. The old repo should be locked, and the new repo 
> should have a new name to avoid any confusion.

What I've done in the past is to:
a) Write-lock the old repository;
b) Create and populate a new repository by whatever means are required;
c) Ensure nobody is trying to access either repository for the next few steps 
(pause Apache, or whatever);
d) Re-name the OLD repository to reflect its broken/BDB/whatever status;
e) Rename the NEW repository to the old name; and, finally:
f) Re-enable access to the repositories.

I even created a batch file to do this when we upgraded SVN recently and could 
no longer access the BDB repositories.

> This is one of the difficulties with the absolute central 
> repository approach of Subversion and its spiritual ancestor, 
> CVS. If anything happens to the central repository, you have 
> to re-establish the effectively server/client relationship 
> correctly or be at risk of corrupting your history, *again*.

This is why your servers should have an effective backup and restoration 
system.  Ours uses a SAN with off-site backup.  Then, if we catch the 
corruption early enough we've only lost a day's history.

> It can happen with more distributed systems as well, it's 
> just more likely when one particular repository is considered 
> canonical in your particular workflow. If the history is 
> replaced or corrupted behind your back, you can be in real trouble.

I think this is true of any single-site storage system - electronic or 
otherwise.  If there's a single point of failure, and you rely on the 
information/items, there's potential for (business) disaster.

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: fsfs storage

[Geoff Field]

From: NS Klanten
Sent: Monday, 11 May 2015 6:20 AM
Subject: fsfs storage


Hello all, 

Where  are the "initial" or base  text files (source codes) are stored 
in fsfs storage ?

I commit a new source code to my svn server, however after searching 
all the related svn folders in my server, I can not find the plain text file. I 
assume that source code is just stored as plain text in fsfs storage and it 
isn't hashed, is my assumption correct?


Thanks in advance for your help,
Jennifer Brooks.

Hi Jennifer,
 
The files are stored in original format in your working copy under 
./.svn/pristine/*, but with hashed names.
 
On the server, they're stored under ./db/revs as a series of deltas.  If you 
look at ./db/revs/0 with a text editor, for example, you'll see it starts with 
the word "PLAIN".  Every other file from there on starts with the word "DELTA". 
 For the sake of efficient storage, there is no plain storage of the original 
files.  You'll find this with many version control systems.
 
If you're only storing text files, there's half a chance of understanding 
what's stored in the delta files.  I wouldn't even consider editing them, 
though.
 
There is probably a setting somewhere to allow a "shadow" version to be set up 
somewhere - if not, it would be a nice idea.  I know in SourceSafe, I was able 
to set up "shadow" folders on a server so that changes were automatically 
updated.  I suspect that SubVersion would require a server-side post-commit 
hook to be written to do the same job.  Does anybody have one they could share?

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: Something like svn:executable for the read-only bit?

[Geoff Field]

> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com] 
> Sent: Thursday, 16 July 2015 10:53 AM
> To: users@subversion.apache.org
> Subject: Re: Something like svn:executable for the read-only bit?
> 
> On 16.07.2015 02:41, Evan Driscoll wrote:
> > We have some generated files that, for logistical reasons, are way 
> > easier to just check into the respository alongside the 
> source than to 
> > build on-demand. (They're small text files, not some big binary or 
> > something like that.)
> >
> > Is there a way to instruct Subversion to remove write access when 
> > checking them out?
> >
> > Obviously the user could just chmod them to add it back, 
> but the point 
> > is just to avoid someone unintentionally modifying the 
> generated file 
> > instead of the source, not to keep people from being jerks. :-)
> 
> Setting the svn:needs-lock property will make files in the 
> working copy read-only.

Hi Evan,

You can even do this automatically from the client settings or the server (from 
1.5).  If you look at the SVN book (http://svnbook.red-bean.com/) under Chapter 
3: Advanced Topics -> Properties -> Automatic Property Setting, it talks about 
MIME types.  It says that SVN will automatically set the svn:executable 
property on newly added or imported files whose execute bit is enabled.  By 
enabling auto-props and including a MIME type statement similar to the 
following in your config file, you can automatically set the read-only 
properties:

In our Windows world, we use a registry tool to set it on the client.  Here are 
the relevant bits of our .reg file:

...
[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany]
"enable-auto-props"="yes"
...
[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props]
...
"*.exe"="svn:needs-lock"
...

Obviously, this would need to be updated for your Unix system, but that's what 
we're doing here.  The SVN book should give you good guidance there.

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. 

SVN 1.8.1 Errors - Show Log and Commit New Files

[Geoff Field]

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: E27: Additional errors:
svn: E27: 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

[Geoff Field]

> From: lieven.govaerts
> On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin 
>  wrote:
> > Philip Martin  writes:
> >
> >> Lieven Govaerts  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: E27: Additional errors:
>  svn: E27: 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: Subversion Exception!-line 1619: internal malfunction

[Geoff Field]

> From: Ryan Schmidt
> Sent: Wednesday, 7 August 2013 12:39 PM
> On Aug 6, 2013, at 15:55, Denis Gadelha wrote:
> 
> > Also when trying to show 'svn log'  I'm getting: RA layer request 
> > failed svn: Unexpected HTTP status 501 'Method Not Implemented' on
> 
> Similar error was reported recently on this list.

Several times, too.

> Are you running a very old version of Subversion on the server?

The odds are "yes", given SVN issue #4404.  The next release should fix it, 
from what I've seen.

Regards,

Geoff

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 

RE: SVN 1.8.1 Errors - Show Log and Commit New Files

[Geoff Field]

> 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 
> >  wrote:
> > > Philip Martin  writes:
> > >
> > >> Lieven Govaerts  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: E27: Additional errors:
> > >>>> svn: E27: 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

[Geoff Field]

> From: Philip Martin
> Sent: Friday, 9 August 2013 18:10 PM
> Geoff Field  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
ASVN_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  .
12/08/2013  09:54 AM  ..
12/08/2013  09:54 AM20 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

[Geoff Field]

> From: Geoff Field
> Sent: Monday, 12 August 2013 10:20 AM
> > From: Philip Martin
> > Sent: Friday, 9 August 2013 18:10 PM
> > Geoff Field  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
> ASVN_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  .
> 12/08/2013  09:54 AM  ..
> 12/08/2013  09:54 AM20 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: SVN 1.8.1 Errors - Show Log and Commit New Files

[Geoff Field]

> -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
> > ASVN_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  .
> > 12/08/2013  09:54 AM  ..
> > 12/08/2013  09:54 AM20 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. 




ApacheAccess.log
Description: ApacheAccess.log

RE: SVN 1.8.1 Errors - Show Log and Commit New Files

[Geoff Field]

> From: Philip Martin
> Sent: Tuesday, 13 August 2013 19:59 PM
> Geoff Field  writes:
> >> -Original Message-
> >> From: Philip Martin
> >> Sent: Monday, 12 August 2013 18:57 PM Geoff Field writes:
> >> 
> >> I can't reproduce that.  Can you look in the apache log 
> files to see 
> >> the failed request?  Can you reproduce the problem over http?  Can 
> >> you provide a network trace?
> >
> > I have emailed Philip and Lieven directly with the network 
> trace file 
> > as it's a bit big (600-odd K) for a mailing list.
> 
> It's an https trace so not much use to me.

That's a shame.  

> > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "PROPPATCH 
> > 
> /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8
> > 97 HTTP/1.1" 401 580
> > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "PROPPATCH 
> > 
> /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8
> > 97 HTTP/1.1" 207 475
> > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "CHECKOUT 
> > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 401 580
> > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "CHECKOUT 
> > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "HEAD 
> > /Subversion/Playground/trunk/test4.txt HTTP/1.1" 401 -
> 
> When I try to reproduce the problem I get a HEAD request that 
> generates
> "404 not found" rather than "401 unauthorized".  What sort of 
> authentication have you configured?  Are you using path-based authz?

Here's what I think is the relevant section of our httpd.conf:


  DAV svn
  SVNParentPath L:/Subversion/Repositories
  SVNAutoversioning on

  AuthType SSPI
  AuthName "Subversion repositories"
  Require valid-user
  SSPIAuth On
  SSPIAuthoritative On
  SSPIDomain AAPL
  SSPIOfferBasic On
  SSLRequireSSL
#  SSPIUsernameCase lower ## Breaks authentication
#  SSPIPerRequestAuth Off ## This breaks Apache2

  AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf

Note that we're running Apache 2.0.  Here are the exact details from the 
server's "Services" applet:

 Apache/2.0.54 (Win32) DAV/2
 mod_ssl/2.0.55
 OpenSSL/0.9.8 SVN/1.2.3
 mod_python/3.1.3
 Python/2.3.5 PHP/5.0.4
 mod_auth_sspi/1.0.3

I'm trying (as a background task from my regular job) to upgrade to Apache 2.2, 
but it's proving to be a bit of a learning experience.

Part of our issue is that the people who originally set it all up (and who 
started doing the upgrade once upon a time) have moved on to other jobs.  
Another part is that maintenance of SVN is a very small part of my job - so 
small it's under "other duties as directed" in the position description, along 
with numerous other tasks.  (I guess many of us on this mailing list will be in 
similar positions, too.)

I'm still learning, even 25+ years into my work life...

Thanks for your patience.

Regards,

Geoff




- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 

RE: SVN 1.8.1 Errors - Show Log and Commit New Files

[Geoff Field]

> 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:
> >
> > 
> >   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
ASVN_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: E29: Commit failed (details follow):
svn: E29: '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 
/Subversi

RE: SVN 1.8.1 Errors - Show Log and Commit New Files

[Geoff Field]

> 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
ASVN_Test\test7.txt
ASVN_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] S

RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)

[Geoff Field]

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 - SOLVED (FOR ME)

[Geoff Field]

> 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)

[Geoff Field]

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. 

RE: Are there SVN consultants out there who remember the ol' days?

[Geoff Field]

Hi Dana
 

From: Dana Epp
Sent: Saturday, 17 August 2013 4:47 AM

We have an old SVN database corruption we need help with. (SVN 1.1 with 
BDB 4.2)
 
Does anyone know of someone who consults on this sort of thing?


We've been dealing with SVN 1.2.3 for a long time, and have developed a process 
for dealing with corrupted databases.  Below is a copy from our (internal) Wiki 
page.  I hope it helps you and others.

Regards,

Geoff


Recovering Corrupted Repositories
Simple Corruption (Log File)

Very occasionally, a file is committed to a repository which causes the 
repository to be corrupted. This usually manifests itself as access to the 
repository freezing. See the extensive notes in Mantis Issue 7585 . Here are 
the steps required to recover:

Warn everybody that SubVersion is about to go down! Remember that some 
repositories may not be corrupt.
Locate a drive with sufficient spare space for the affected repositories
Log onto the SubVersion server. This requires administrative access, which 
is limited to a very small number of people.
Stop the Apache service
Backup the affected repositories
Remove the log files which don't have the db version as 0x0A in the 16th 
byte of the offending log file. For example, log.02030 had a db version 
of 0x0b.
Run "db_recover" from within the db directory of the repository. This 
requires the utility to be in the path (C:\Program Files\Sleepycat 
Software\Berkeley DB 4.3.29\bin)
Run "svnadmin recover .\" from within the repo directory (i.e. one above 
the db dir)
Re-start the Apache service
Inform everybody that SubVersion is back up.

Note Sometimes db_recover does not work. In this case, the "-c" flag helps for 
"critical errors"


Serious Corruption (Database)
From 
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1617554

 "Nicholas Walker" 
 Full name "Nicholas Walker" 
 Date 2009-04-09 13:31:59 PDT
 Message I went through a week of trying to resolve various issues with 
an old 
 out of control corrupted v 1.4 Berkeley Db subversion repository.


 These steps will not work for an fsfs repository.


 I put together a process for how I resolved my issues. I hope it helps 
somebody else 
 out.


 Note: This process does not solve corruption, it just puts the repository into 
a state 
 where svnadmin dump will not fail. The steps below will result in specific 
histories 
 being lost. If you have the option to go back to recent backup to resolve the 
issue that 
 would be a much better strategy. But when the repository has not been 
maintained for 
 ears as in my case there is no other way.


 You'll need to use the Berkeley db utilities that match the version of 
Berkeley db that 
 is being used in your repository in my case those utilities were found in 
 "/usr/local/bin/db42". The path , and executables on your machine may not 
match mine.


Copy repository to a temporary location.
You can use svnadmin hotcopy REPOS_PATH NEW_REPOS_PATH
Resolve pure database corruption
This resolves error similar to DB_PAGE_NOT_FOUND error.
There are files in [repository Path]/db
Changes
Copies
Nodes
Representations
Revisions
Strings
Transactions
uuids
Each of these represent a database table
Run "/usr/local/bin/db42/db_dump -r File > File.dump" against each of 
the files.
This dumps the database table to a dump file, and removes instances 
where corruption has occurred.
Note that this will remove corrupted file commits from the database 
table, but they were irrecoverable anyway so it doesn't matter.
If you have a large repository the dump and reload process make 
take a considerable amount of time, especially for the strings table.
Run "rm [File]" for each of the files.
Delete the file not the .dump file
Run "/usr/local/bin/db42/db_load File < File.dump" for each of the 
files.
This is wonderful in theory, but I have found that the version of 
db_load we currently have does not like the format of the file output by 
db_dump on Windows: db_dump puts CR/LF on the end of each line, while db_load 
does not like this. To correct this:
Open the file in Notepad++
View the file in Hex (Alt-Ctrl-Shift-H)
Highlight the first 0d 0a.
Select Search->Replace (Ctrl-H)
Enter "0d" (that's number 0, not letter O) in the "Replace 
with" field
Click on "Replace All"
Save the file.
Since the process takes a long time, you may want to make a backup of your 
backup in case you mess up in the next steps, you have a half way point to 
revert to, since step 2 can take a long time.
Resolve repository corruption
These erro

RE: svn 1.8.1 fails on underscore in the tunnel protocol

[Geoff Field]

> From: Bert Huijben
> Sent: Saturday, 17 August 2013 9:18 AM
> > From: Branko Čibej
> > Sent: vrijdag 16 augustus 2013 23:29
> > On 16.08.2013 23:10, Eric Hall wrote:
> > > Hello-
> > >   We have a custom tunnel protocol withrepository URLs of 
> the form:
> > >
> > >   svn+foo_bar://
> > >
> > >   After upgrading from svn 1.7.x to 1.8.1, these URLs are 
> considered 
> > > invalid, giving an error of:
> > >
> > >   svn: E17: Illegal repository URL
> > >
> > >   This occurs on an 'svn up' or an 'svn checkout'.
> > >
> > >   Changing the tunnel protocol name to 'foobar' (i.e. drop the
> > underscore)
> > > appears to work properly, both 'svn up' and 'svn 
> checkout' work fine.
> > >
> > >   Is this a bug, or should tunnel protocols not have 
> underscores in
> > them?
> > 
> > See RFC 3986, section 3.1:
> > 
> > http://www.ietf.org/rfc/rfc3986.txt
> > 
> > Underscores are not allowed in the URL scheme. It would appear that 
> > allowing them was a bug in previous versions of Subversion.

Reading through that RFC, I note the following paragraph:

2.3.  Unreserved Characters

   Characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include uppercase and lowercase
   letters, decimal digits, hyphen, period, underscore, and tilde.

  unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

To me, this quite clearly states that underscores ARE permitted in URLs.  Any 
code that fails to allow them is contrary to the RFC.


> The related change was not in Subversion itself, but in 
> apr-util 1.5.2.
> [[
>   *) apr_uri_parse(): Do not accept invalid characters in the scheme.
>  Per RFC 3986 3.3, enforce that the first segment of a 
> relative path does
>  not contain a colon. PR 52479.
> ]]

That's about a colon, not an underscore.

Regards,

Geoff

-- 
Apologies for the auto-generated 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. 

How Big A Dump File Can Be Handled?

[Geoff Field]

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: How Big A Dump File Can Be Handled?

[Geoff Field]

> 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 informa

RE: How Big A Dump File Can Be Handled?

[Geoff Field]

> 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?

[Geoff Field]

> 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?

[Geoff Field]

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? (svn 1.8 upgrade)

[Geoff Field]

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)

[Geoff Field]

> 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: Planning a SVN upgrade

[Geoff Field]

From: Mark Phippard
Sent: Saturday, 24 August 2013 6:35 AM
On Fri, Aug 23, 2013 at 4:09 PM, Maureen Barger wrote:

I am currently planning an upgrade from SVN 1.5 (using svnserve and
ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for
authNz.
We have about 50 repos. I'll be moving from an older Ubuntu 8 install
to Centos 6 x64.

We have just upgraded our server from 1.2.3 to 1.8.1, including a move from 
Apache 2.0 to Apache2.2.
It took me some time, but it was done as a bit of a background task.  There 
were 74 BDB repositories that had to be dumped and loaded to FSFS format.


My thought was I could upgrade the SVN installation in place, bringing
the repo up to 1.8 and then dump those repos and bring them online in
the new environment.

If it were me, I would not upgrade the repositories.  SVN 1.8 can just serve 
the old repositories.  I would do the upgrade and only after I was using it for 
a while would I then consider to start doing a dump/load on the repositories.  
You could then do them one by one as desired.  The main benefit in upgrading 
the repository is to use less disk space.
I also would not upgrade existing repositories just for the sake of it.  If 
there's a feature you feel would be useful that's only available with the 1.8 
repo format, then I would do it, but ONLY for the active repos.  The only 
reason I upgraded the BDB repositories was because I could no longer access 
them with the new server software.  Even then, I left them in the 1.2 format in 
case we had to go back to the original server for some reason.

If you're going to do an upgrade on the repositories, make sure you back them 
up first.  Then the disk space issue becomes moot, because the backups take 
space as well.
We currently use Eclipse as our IDE and Jenkins as our CI tool with
Nexus as the object repo. I was thinking to leave the upgrade of
Eclipse client and svnkit to the indiviidual so they can decide what
direction to take with their working copies et al.

Yes, your clients can already be using 1.8 if they want to.  There is no need 
to upgrade the client either before or after the server.  Let the clients 
manage it.  Only exception is if there are specific new features you want to 
implement across the board.  If you do a lot of branching and merging, it would 
be a good idea for the people that do merge to all be using the same version.  
Likewise, there are other features that might be like this.

I concur.  (Of course, Mark has a lot more SVN experience and in-depth 
knowledge than I do.)   Leave it to the individual to decide whether to 
upgrade.  There are very few cases where the server and client software are 
incompatible between versions.  Mind you, I did have to do our upgrade to the 
server because version 1.8.x of the client doesn't play nicely with version 
1.2.x of the server, in terms of adding new files and displaying logs.  That's 
how I came to join the mailing lists in the first place.

I do not foresee
any changes I would need to make to Jenkins or Nexus.

Just the URL to access the repository will change.

Even that doesn't have to change.  We're using the same URLs.

Has anyone made a jump this large before? Any comments about my upgrade plan?

There is nothing unusual about this.  People have jumped from 1.1 to 1.8.

In my case, 1.2 to 1.8.  By comparison, 1.5 to 1.8 should be easy.

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: Unsubscribe

[Geoff Field]

Hi Venkat,

You need to send an email to 
users-unsubscr...@subversion.apache.org
 to unsubscribe from this list.

Regards,

Geoff



From: Badipatla, Venkata [mailto:venkata.badipa...@capgemini.com]
Sent: Wednesday, 28 August 2013 15:03 PM
To: users@subversion.apache.org
Subject: Unsubscribe

Unsubscribe

Thanks & Regards,
Venkat
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.


--
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: Unsubscribe

[Geoff Field]

> From: Andreas Mohr
> Sent: Wednesday, 28 August 2013 15:49 PM
> On Wed, Aug 28, 2013 at 03:07:15PM +1000, Geoff Field wrote:
> >You need to send an email to 
> [1]users-unsubscr...@subversion.apache.org to
> >unsubscribe from this list.
> 
> ...as can in most cases of mailing lists be determined via an 
> email header line:
> 
> || List-Unsubscribe: 
> <mailto:users-unsubscr...@subversion.apache.org> ||

I don't know if our company filters stripped it out, but OutHouse^w OutLook did 
not show a header anything like this when I did the (ahem) *intuitive* 
"View->Options" trick.

> , if mail headers of a mail are viewable (which may 
> unfortunately not be the case with "less capable" - ahem - MUAs).

Some of us are stuck with what our IT departments give us to work with.  If you 
want to work with an Exchange server, it's easiest (and most compatible) to 
work with Outlook - particularly if the PC has it preinstalled.

In reality, Outlook is not that bad an email client - provided you don't want 
to do technical things with it.  The integration with the calendar 
functionality is particularly valuable for those of us who lose track of time 
when working.  Voting is a nice feature, too, that we sometimes use.

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: Unsubscribe

[Geoff Field]

Hi Brane,

> Outlook (and Exchange)  have been known to strip headers that 
> are "not important" to users.

Micro$oft being "helpful" again...

> We do have the procedures 
> documented here, however:
> 
> http://subversion.apache.org/mailing-lists.html

Which is where I dredged up the advice to the OP.

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 commit line ending handling

[Geoff Field]

> From: Ryan Schmidt 
> Sent: Sunday, 1 September 2013 8:21 AM
> On Aug 31, 2013, at 05:29, Edoardo Pinci wrote:
> > I periodically receive this kind of errors since a long time.
> >  
> > X:\>svn commit -m "BLA BLA" itextsharp.dll iTextSharp.xml
> > SendingiTextSharp.xml
> > Sendingitextsharp.dll
> > Transmitting file data ..
> > svn: E135000: Commit failed (details follow):
> > svn: E135000: While preparing 'iTextSharp.xml' for commit
> > svn: E135000: Inconsistent line ending style

I've seen this a few times when committing an auto-generated XML file - mostly 
because it was encoded as UTF-16.

> > svn: E720032: Additional errors:
> > svn: E720032: Transaction '1718-1ca' cleanup failed
> > svn: E720032: Can't remove file 
> 'Depot\db\txn-protorevs\1718-1ca.rev': The process cannot 
> access the file because it is being used by another process.

Since I've been using the TortoiseSVN client, I haven't noticed whether these 
additional errors popped up as well.

> > Question 1: Is there a way to have SVN normalize line 
> ending on commit by itself?
> 
> It seems svn:eol-style is set on this file. If you set 
> svn:eol-style on a file (to any supported value), Subversion 
> requires that the file have consistent line endings before 
> you commit it. You or your tools must do this; Subversion will not.

I was going to ask "why not?"  However, I realised this is because the SVN 
philosophy is to not change files unless explicitly requested to (with 
keywords).

> If you do not set svn:eol-style, then Subversion does not 
> check the line endings and lets you commit whatever you want, 
> so if for some reason you want inconsistent line endings then 
> that's how you can have that.

If the file's encoded as UTF-16, it will give this error regardless of the 
consistency of the line endings.  I've found the easiest way around this (for 
me) is to copy and paste the contents of the XML file into a new file encoded 
as UTF-8, then save it over the top of the original file.  Notepad++ is my 
preferred option for this at the moment, but any text editor should do the job.

> > Question 2: Why txn-protorevs aren't being cleaned up properly?
> 
> I don't know what's going on there. Do you have any hook 
> scripts? Maybe one of them is programmed incorrectly.


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 commit line ending handling

[Geoff Field]

Hi Thorsten,

> Guten Tag Geoff Field,
> am Montag, 2. September 2013 um 01:09 schrieben Sie:
> 
> > If the file's encoded as UTF-16, it will give this error 
> regardless of 
> > the consistency of the line endings.
> 
> I successfully committed UTF-16 some minutes ago, Subversion 
> doesn't care about the character set of the files.

Last time I did a commit of this file, I was using TortoiseSVN version 1.7.13 
(or earlier) on a Windows system.

The properties include svn:eol-style=native and svn:mime-type=text/xml (this 
latter is probably from autoprops).

> The 
> problem in your case surely was because of inconsistent line 
> endings as well.

It's possible.  I did look at the file with a hex editor to try to fix things, 
but didn't see any inconsistent line endings.  Of course, this does not mean 
there were none, just that I didn't see them.

In the hex editor, the line endings were all encoded as 00 0d 00 0a.  Given the 
"native" eol style, I think SVN might have been looking for 0d 0a without the 
padding.  SVN might even have seen the 00 0d as one line ending and the 00 0a 
as the next.

Since the file is auto-generated as part of an installation package, one would 
hope the auto-generation tool would make the endings consistent.  However, hope 
is no substitute for reality.

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: Breaking up a monolothic repository

[Geoff Field]

> From: Trent W. Buck
> Sent: Monday, 9 September 2013 12:17 PM
> Nico Kadel-Garcia  writes:
> 
> > Lock the existing repo: Do clean exports, and imports, to new 
> > repositories with the new layout, with a README.md or other 
> guideline 
> > to where the legacy repository exists. You lose the infinitely 
> > preserved history this way, but for most working software projects, 
> > you don't *need* that. And it's a good opportunity to discard 
> > materials, such as bulky binaries or security sensitive 
> files with plain text passwords.
> 
> Ah, sorry, I forgot to mention that preserving history was a 
> hard requirement handed down from higher up.

You *could* argue that the existing repository preserves the history.
However, I think I know what they mean.

> I get the impression that $company's projects mostly have a 
> finite lifespan (a couple of years),

By "lifespan", what exactly do you mean?  At my company, the individual 
projects might be in production within anywhere from 6 months to 2 years after 
start of development, be manufactured for two to four years, then go into 
support mode for up to 7 years (or more).

> so I think that approach 
> ends up being very similar to my current plan of creating new 
> projects as new repos, and letting the monolithic repo die 
> out via attrition.

That sounds like an easy way to do things.

> I don't actually know exactly what they put in their repos; I 
> think it's about half "huge unpacked source tarball I 
> downloaded from somewhere then tinkered with" and half huge 
> CAD files and .docx contracts.

It's entirely possible that the empty commit messages you reported were due to 
users not actually entering anything in the messages.  Many of the commit 
messages I've seen (particularly from non-software people, but even from a few 
of those) are less informative than I'd like - a lot are totally empty.

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: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Hi Bert,



From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker 
already?

No,

There is no issue for this specific part of those threads created as nobody was 
able to produce a reproduction recipe for this problem to the developers yet.
Surely it would be useful to add the issue report anyway, even if there is no 
easy way to reproduce it.  After all, it is a known issue now.  We can then 
work on the reproduction recipe.

All the threads you quoted end with this request... So unless you add a way to 
reproduce the problem (perhaps with the help of the earlier reporters) to the 
discussion there is not much we can do for you at this time/
I'm sure I posted the method for me to reproduce it.We were running a 1.2.3 
server served by Apache 2.0.54 on Windows Server 2003 SP2.  I was then using a 
1.8.1 client on Windows 7 Pro 32-bit.  I thought I'd posted my recipe here:

http://svn.haxx.se/users/archive-2013-08/0035.shtml

However, this is NOT the full recipe. Instead, look at this post:

http://svn.haxx.se/users/archive-2013-08/0140.shtml

That contains the steps I took to reliably produce errors with the 
server/client setup we had.  Unlike most of our repositories, the Playground 
repo has always been FSFS.  The problem happened with our BDB repos as well.
The problem doesn't reproduce with the currently supported versions, nor with 
the older versions we tried to setup specifically to trigger the problem quoted 
here.
But it's easily reproduced here, and obviously is at other sites too.

Do you see the problem in all working copies, or just in certain scenarios? 
(E.g. multiple levels of added directories? Mixed revision copies? Etc. etc.)
I saw it in nearly every case.  There were rare occasions when the add/commit 
would just work, but in the majority of cases it would fail.

Bert

From: JANIKOVIC Jan [mailto:jan.janiko...@power.alstom.com]
Sent: dinsdag 24 september 2013 12:51
To: users@subversion.apache.org
Subject: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

Hello,

There seems to be a problem with the TortoiseSVN1.8.0+, which returns a server 
conflict when a new file is attempted to be added. We observed the problem only 
when adding files to the server running SVN1.5.5. No problems were observed 
when adding files to our second server, running SVN 1.7.x. There are further 
posts about this issue on the Internet, such as 
https://groups.google.com/d/topic/tortoisesvn/cGoClRBMCPc/discussion
or
https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ

Is this issue already in the Subversion tracker 
(http://subversion.apache.org/reporting-issues.html)? If yes, could you please 
tell me the issue number

Kind regards
Jan

Jan Janikovic
ALPRO Implementation Specialist
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: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Good evening Thorsten,

> Guten Tag Geoff Field,
> am Mittwoch, 25. September 2013 um 02:25 schrieben Sie:
> 
> > Hi Bert,[...]
> 
> Please don't rely on everyone is seeing HTML mails by 
> default,

My apologies.  My only excuse (apart from laziness) is that the post to which I 
replied was in HTML.

> I don't and your answer is almost useless as plain text.

And I thought *I* was a throwback ;-)

> http://www.netmeister.org/news/learn2quote.html

There's a difference between "being taught" and "learning".  The latter relies 
on actually *remembering* what a teacher has tried to hammer through one's 
skull.

For those who do not or will not run an email client with HTML capabilities 
turned on, here is the post in plain text format:

From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker 
already?

> There is no issue for this specific part of those threads created as nobody 
> was able to produce a reproduction recipe
> for this problem to the developers yet. 

Surely it would be useful to add the issue report anyway, even if there is no 
easy way to reproduce it.  After all, it is a known issue now.  We can then 
work on the reproduction recipe.

> All the threads you quoted end with this request. So unless you add a way to 
> reproduce the problem (perhaps with the
> help of the earlier reporters) to the discussion there is not much we can do 
> for you at this time/

I'm sure I posted the method for me to reproduce it.We were running a 1.2.3 
server served by Apache 2.0.54 on Windows Server 2003 SP2.  I was then using a 
1.8.1 client on Windows 7 Pro 32-bit.  I thought I'd posted my recipe here:

http://svn.haxx.se/users/archive-2013-08/0035.shtml 

However, this is NOT the full recipe. Instead, look at this post:

http://svn.haxx.se/users/archive-2013-08/0140.shtml

That contains the steps I took to reliably produce errors with the 
server/client setup we had.  Unlike most of our repositories, the Playground 
repo has always been FSFS.  The problem happened with our BDB repos as well.

> The problem doesn't reproduce with the currently supported versions, nor with 
> the older versions we tried to setup
> specifically to trigger the problem quoted here.

But it's easily reproduced here, and obviously is at other sites too.

>  Do you see the problem in all working copies, or just in certain scenarios? 
> (E.g. multiple levels of added
> directories? Mixed revision copies? Etc. etc.)

I saw it in nearly every case.  There were rare occasions when the add/commit 
would just work, but in the majority of cases it would fail.  


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: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Hi Bert,

From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Wednesday, 25 September 2013 21:04 PM
To: Geoff Field; 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the 
tracker already?



>   I'll just reply in the html form as it will be very hard to convert 
> this thread to plain ascii and I have better things to do than spending half 
> an hour on that.

As much as Outlook (and I know you're using Outlook because the headers of your 
message include "X-Mailer: Microsoft Outlook 15.0") is a sub-optimal tool for 
traditional groups, it's not that hard to change the "Format" selection from 
"HTML" to "Plain Text".

The real problem/pain is that you then have to reformat the message to make 
sense in plain-text format.  I haven't done much to this message and it's a bit 
of a mess.

>   The information in your e-mail says that you can reproduce it on your 
> working copy; and then Philip Martin says he can't reproduce it.

I've given as much detail as I can in the various emails, but I think Philip 
has had problems getting the exact version loaded.

>   I looked through your apache log (attached in yet another followup) and 
> noticed that about every request first fails with a 401 error and then later 
> succeeds.

Yes, that seems to be happening a lot.  Even now after updating versions I'm 
getting a lot of 401s in the log.

>   What authentication configuration does your apache use?

We're using an authz file.  Specifically, we have:

Options Indexes FollowSymLinks

DAV svn
SVNListParentPath On
SVNParentPath L:/Subversion/Repositories
SSLRequireSSL

# Keep these in sync with location /websvn below
AuthType SSPI
#   AuthType None
AuthName "Subversion repositories"
SSPIAuth On
SSPIAuthoritative On
SSPIDomain AAPL
SSPIOfferBasic On
Require valid-user

AuthzSVNAccessFile L:/Subversion/conf/svnaccessfile.conf


And yes, I've just double-checked that the /websvn location is identical.

 
>   NTLM/Digest/Basic, with what backend.

Our LoadModules for auth connections include the following lines (omitting the 
commented-out ones):

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule sspi_auth_module modules/mod_auth_sspi.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_svn_module modules/mod_authz_svn.so

On the server, the Services applet gives the following Description information 
for Apache 2 (which is no longer active because it's where we get the problems):

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

If I've missed anything important, please feel free to give me more detailed 
information on what you need.

>   What is the maximum number of requests per connection?

I'm not entirely sure.  From the Apache2 httpd.conf, I see:


ThreadsPerChild 250
MaxRequestsPerChild  0


I'm not entirely sure if the mpm_winnt module is enabled.


>   Can you send us your apache config (with sensitive information replaced 
> by dummy information of course)

I'll reply off-list with the full httpd.conf for Apache2.  There is nothing in 
there that I consider secret.  The authz file is another story, of course, but 
I'll send a copy of that with just the Playground repo information.

>   Thanks,
>
>   Bert

And thanks for your attention and patience, too.

Regards,

Geoff
 

 

 

From: Geoff Field [mailto:geoff_fi...@aapl.com.au] 
Sent: woensdag 25 september 2013 02:25
To: Bert Huijben; 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the 
tracker already?

 

Hi Bert,

 

 



From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in 
the tracker already?

No,

 

There is no issue for this specific part of those threads 
created as nobody was able 

RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Thanks Bert,

I appreciate the effort.

(Top-posting, but at least it's in plain-text format...)

Geoff
 

-- 
Apologies for the auto-generated legal boilerplate added by our IT department:


 




From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Thursday, 26 September 2013 2:13 AM
    To: Geoff Field; 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the 
tracker already?



I think I found a bug causing your specific problems in 'serf', 
Subversions new default http library.

 

The problem doesn't appear to affect Subversion users unless the server 
closes connections aggressively. 'HEAD' requests (as requests without a body) 
don't trigger the authentication subsystem. The 401 from the HEAD request as 
shown in your log file is assumed to be a 'file exists' status.

 

A patch is available on the serf development list. I assume it (or a 
similar patch) will be included in the next serf version.

 

Bert

 

From: Bert Huijben [mailto:b...@qqmail.nl] 
    Sent: woensdag 25 september 2013 13:04
To: 'Geoff Field'; 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the 
tracker already?

 

I'll just reply in the html form as it will be very hard to convert 
this thread to plain ascii and I have better things to do than spending half an 
hour on that.

 

The information in your e-mail says that you can reproduce it on your 
working copy; and then Philip Martin says he can't reproduce it.

 

I looked through your apache log (attached in yet another followup) and 
noticed that about every request first fails with a 401 error and then later 
succeeds.

 

What authentication configuration does your apache use?

 

NTLM/Digest/Basic, with what backend.

What is the maximum number of requests per connection?

 

Can you send us your apache config (with sensitive information replaced 
by dummy information of course)

 

Thanks,

    Bert

 

 

 

From: Geoff Field [mailto:geoff_fi...@aapl.com.au] 
Sent: woensdag 25 september 2013 02:25
To: Bert Huijben; 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the 
tracker already?

 

Hi Bert,

 

 



From: Bert Huijben [mailto:b...@qqmail.nl 
<mailto:b...@qqmail.nl> ] 
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; users@subversion.apache.org 
<mailto:users@subversion.apache.org> 
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in 
the tracker already?

No,

 

There is no issue for this specific part of those threads 
created as nobody was able to produce a reproduction recipe for this problem to 
the developers yet. 

Surely it would be useful to add the issue report anyway, even if there 
is no easy way to reproduce it.  After all, it is a known issue now.  We can 
then work on the reproduction recipe.

 

All the threads you quoted end with this request... So unless 
you add a way to reproduce the problem (perhaps with the help of the earlier 
reporters) to the discussion there is not much we can do for you at this time/

I'm sure I postedthe method for me to reproduce it.We were running 
a 1.2.3 server served by Apache 2.0.54 on Windows Server 2003 SP2.  I was then 
using a 1.8.1 client on Windows 7 Pro 32-bit.  I thought I'd posted my recipe 
here:

 

http://svn.haxx.se/users/archive-2013-08/0035.shtml 
<http://svn.haxx.se/users/archive-2013-08/0035.shtml> 

However, this is NOT the full recipe. Instead, look at this post:

http://svn.haxx.se/users/archive-2013-08/0140.shtml 
<http://svn.haxx.se/users/archive-2013-08/0140.shtml> 

That contains the steps I took to reliably produce errors with the 
server/client setup we had.  Unlike most of our repositories, the Playground 
repo has always been FSFS.  The problem happened with our BDB repos as well.

The problem doesn't reproduce with the currently supported 
versions, nor with the older versions we tried to setup specifically to trigger 
the problem quoted here.

But it's easily reproduced here, and obviously is at other sites too.

 

  

RE: Outlook macro for proper quoting (was RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?)

[Geoff Field]

> From: Andrew Reedick
> > From: Geoff Field
> > Sent: Wednesday, September 25, 2013 7:27 PM
> > Hi Bert,
> > 
> > From: Bert Huijben
> > Sent: Wednesday, 25 September 2013 21:04 PM
> > 
> >>I'll just reply in the html form as it will be very hard to
> > convert this thread to plain ascii and I have better things 
> to do than 
> > spending half an hour on that.
> > 
> > As much as Outlook (and I know you're using Outlook because the 
> > headers of your message include "X-Mailer: Microsoft 
> Outlook 15.0") is 
> > a sub- optimal tool for traditional groups, it's not that hard to 
> > change the "Format" selection from "HTML" to "Plain Text".
> > 
> > The real problem/pain is that you then have to reformat the 
> message to 
> > make sense in plain-text format.  I haven't done much to 
> this message 
> > and it's a bit of a mess.
> 
> For those suffering from the embarrassment of posting with 
> Outlook clients:  "QuoteFix Macro" at 
> http://sourceforge.net/apps/mediawiki/macros4outlook/index.php?title=QuoteFix_Macro#Configuration

Thanks Andrew,

I've found that with a very small effort and a little manual
configuration, I can produce a reasonably formatted post without
upsetting the modern conventions used by most of the others
within our business.

Having said that, I've applied QuoteFix on my Outlook Express at
home (some time in the past).  I'm reluctant to apply it on my
work computers, though - if our firewall even allows downloads
from SourceForge (it's a bit fussy in some very odd ways).

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: Recommendation for path-based authorisation auditing tool?

[Geoff Field]

Hi David,

I hate to sound like I'm stating the bleeding obvious, but what about just 
looking at the authz file with a text editor?

It's not hard to interpret if your usernames are sensible.  I've recently spent 
a little while making sure the projects are sorted in a sensible order, so 
finding particular projects is quite easy (apart from just using the built-in 
search functions).

Having said that, we use a home-grown tool (written by a long-gone colleague in 
C# and backed by an SQL database for administration items) for some network 
administration tasks.  Mostly, this is useful as a lazy way of adding or 
deleting projects.  I still use the text editor for modifying user permissions 
(because it's faster and easier).

Regards,

Geoff

From: David Aldrich
Sent: Friday, 27 September 2013 1:08 AM

Hi Mark

Thanks, that's a very helpful suggestion.

Best regards

David

 

From: Mark Phippard
Sent: 26 September 2013 16:06

On Thu, Sep 26, 2013 at 11:02 AM, David Aldrich  wrote:

Hi Mark

Thanks for replying.  By auditing, I mean the ability to easily 
see who has access to a specified folder.  I think we already have the 
recording of changes covered.  svnauthz_accessof looks interesting, but it 
reports whether a specified user has access.  I would prefer to ask 'who has 
access?' to a specified folder.

OK.  I am not aware of any tools commercial or otherwise that provide 
the information that way.  If you use groups and have a finite number of them, 
it seems like it would be a fairly simple script to check each group against 
the path using the command line tool and report which ones have access.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/ 

-- 
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 to unsubscribe

[Geoff Field]

Hi there,

You need to send an email to 
users-unsubscr...@subversion.apache.org<mailto:users-unsubscr...@subversion.apache.org?subject=unsubscribe>
 to unsubscribe from this list.

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




From: chenc...@gmail.com [mailto:chenc...@gmail.com]
Sent: Sunday, 20 October 2013 16:02 PM
To: users@subversion.apache.org
Subject: how to unsubscribe

how to unsubscribe ?


chenc...@gmail.com

From: Ivan Zhakov<mailto:i...@visualsvn.com>
Date: 2013-10-18 22:22
To: Karol Szkudlarek<mailto:ka...@mikronika.com.pl>
CC: brane<mailto:br...@wandisco.com>; Bob Archer<mailto:bob.arc...@amsi.com>; 
users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: Re: svn 1.8.3 on windows often crashes
On 18 October 2013 18:06, Karol Szkudlarek  wrote:
>
> I'm asked about:
>
> " OK. So please tell me whether this fix (r152289) for issue
>> #4425 is already merged to branch 1.8.x?!("
>
> Ivan's answer is not enough for me. Ivan wrote:
>
> "Well, I checked logs more carefully and it seems like issue #4425 [1]
> which is fixed in r1522892 and proposed for backport to Subversion
> 1.8.4. "
>
> I don't know whether r1522892 is in trunk (I suppose this) or in destination
> branch 1.8.x.
>
Yes, r1522892 was merged to 1.8.x branch and other user tested 1.8.x
command line binaries (from TortoiseSVN) and confirmed that issue
fixed:
http://svn.haxx.se/users/archive-2013-10/0110.shtml


--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

- 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: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

[Geoff Field]

Sorry to dredge up an old thread, but this issue is NOT really resolved 
properly. (Also, I noticed a post that said that this would be treated more 
seriously if it was brought up again without the "RESOLVED" tag.)

There's a known issue with the Apache server software 
(https://issues.apache.org/bugzilla/show_bug.cgi?id=55306) whereby if the 
directory tree being copied has a lock anywhere in it, the DAV component will 
send a 424 error.  Why a copy should need to be concerned about a lock is a 
mystery.

The so-called "Resolution" listed in the mailing lists here was simply to break 
or release the locks.  It's not really a fix, just a workaround.

The most recent release of Apache is 2.4.6 from July, but the last activity in 
the bug report is from October.  Any idea when the next release is due?  The 
Apache release policy (http://www.apache.org/dev/release.html) doesn't seem to 
tell me  anything significant about that.  (I do realise it's an open source 
project and therefore dependant on people volunteering their time.)

In the meantime, we will all have to continue trying to remember to unlock 
files before attempting a branch, tag, or other copy.  Either that, or revert 
to an earlier version of Apache.


> From: Brenden Walker
> Sent: Thursday, 8 August 2013 6:08 AM
> > From: Bob Archer
> > Sent: Wednesday, August 07, 2013 2:30 PM
> > > > Brenden Walker writes:
> > > > >> > svn: E175002: Adding directory failed: COPY on 
> > > > >> > 
> /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 
> > > > >> > Failed
> > > > >> > Dependency)
> > > > >
> > > > > Turned out that another developer had locks on several files.
> > > > > Confirmed that was the problem.  A more specific 
> error message 
> > > > > would have been handy here.

The error message was reasonably specific, but it actually points at another 
bug.

> > > > Can you describe how to reproduce the problem?  What 
> sort of locks 
> > > > prevent a COPY?  Orphaned locks perhaps?
> > >
> > > They were working copy locks from another developer.  I 
> asked him to 
> > > try the build himself to see if it allows the user who holds the 
> > > lock to svn copy, haven't heard back from that.

ANY lock seems to work.  I was able to reproduce the issue by locking the files 
myself (and to "correct" it by unlocking the files.

> > > Breaking the locks allowed me to do an SVN copy.
> > >
> > > I haven't tried reproducing, but I certainly can if that 
> would be helpful.
> > 
> > Are you sharing working copies with multiple people?
> 
> If by that you mean checking out somewhere and having 
> multiple people using the same working copy, no.  Each 
> developer has their own working copy.  The reason the files 
> were locked is that they're unmergeable binaries, AND most 
> people here are still used to StarTeam.  I offered up some 
> other options to keep other developers from accidentally 
> changing these files.

We, too, have unmergeable binaries, so we use autoprops - including "needs 
lock" properties as appropriate.  This applies for even one-person teams (our 
current default).


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: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

[Geoff Field]

> From: Mark Phippard
> Sent: Friday, 8 November 2013 11:47 AM
> If it helps, the Subversion server binaries we provide at 
> CollabNet have applied the patch that fixed this to Apache 2.4.6.

Thanks Mark,

I'm downloading and installing now, but I'll have to fiddle around with our 
multiple server versions to get it to actually work now.

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: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

[Geoff Field]

> From: Ben Reser
> Sent: Friday, 8 November 2013 11:55 AM
> On 11/7/13 4:31 PM, Geoff Field wrote:
> > Sorry to dredge up an old thread, but this issue is NOT really 
> > resolved properly. (Also, I noticed a post that said that 
> this would 
> > be treated more seriously if it was brought up again without the 
> > "RESOLVED" tag.)
> 
> Not sure what you mean by this.  The issue has been taken 
> seriously, it's just that Apache httpd doesn't release very often.

Sorry, I sometimes fail to word things correctly.  (As a native - and 
monolingual - English speaker, there's little excuse for that.)

I meant that in my research, I saw a post by a developer (somewhere - I no 
longer have a link) that referred to this thread (and a couple of others, I 
think) but said words to the effect of "unfortunately, all the threads mention 
that they're RESOLVED so it's not receiving much attention.  If somebody can 
post again, we can raise the priority."

I'm just trying to bump the priority again, given our circumstances.  
Specifically, the server is a Windows Server 2003 system that's mostly under 
the control of a separate department to my own.  It was originally set up for 
SVN by people who are no longer here and I'm learning as I go.  There is an 
installation of Cygwin on the machine, but no gcc (nor any other development 
systems).  The C: drive (where the programs reside) doesn't have a lot of spare 
space (but I can always drop things on the RAID drive L: where the repositories 
reside).


> > There's a known issue with the Apache server software 
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=55306) 
> whereby if the directory tree being copied has a lock 
> anywhere in it, the DAV component will send a 424 error.  Why 
> a copy should need to be concerned about a lock is a mystery.
> 
> The existing mod_dav module didn't properly comply with the 
> RFC for DAV that specifies that COPY methods should enforce 
> If: headers in the request.

So is it just mod_dav*.so that's affected?

>  Someone decided to fix this, but 
> in the process they proceed to enforce some additional 
> restrictions (specifically that the source and the parent of 
> the source are checked for write access).  In 2.2.25 and 
> 2.4.6 we fixed the requirement of the parent, but missed the 
> issue with the lock on the source itself.  Sadly we found the 
> second issue shortly after the releases and now we're waiting 
> for another release cycle to get it in your hands on a release.

I look forward to release day, but I'll try not to pester people too much about 
it.

> > The so-called "Resolution" listed in the mailing lists here 
> was simply to break or release the locks.  It's not really a 
> fix, just a workaround.
> 
> No I'd say the resolution is to apply the patch that has been 
> written to your httpd.

I agree.  Breaking/releasing locks is NOT a resolution.  Applying patches (or 
patched software) is.  Is there an easy way to apply a patch on a Windows 
server with limited drive space for extra tools such as compilers?

> > The most recent release of Apache is 2.4.6 from July, but the last 
> > activity in the bug report is from October.  Any idea when the next 
> > release is due?  The Apache release policy 
> > (http://www.apache.org/dev/release.html) doesn't seem to tell me  
> > anything significant about that.  (I do realise it's an open source 
> > project and therefore dependant on people volunteering their time.)
> 
> I don't know for sure but there was some desire to do a httpd 
> 2.4.x release in October.  For other reasons unrelated to 
> this it hasn't happened.

You don't mean to say you actually have *lives*?? ;-)

>  I see what I can do to nudge things 
> along.  Unfortunately, as a fairly new httpd committer, I'm 
> not sure how to do the releases myself yet.

Learning curves are fun, aren't they?

> > In the meantime, we will all have to continue trying to 
> remember to unlock files before attempting a branch, tag, or 
> other copy.  Either that, or revert to an earlier version of Apache.
> 
> My suggestion would be to apply the patch to your local 
> httpd.  I'd meant to post some copy of the patches here on 
> the list to help with this for the various mod_dav issues 
> that are floating around out there and had forgotten to do 
> it.  I'll be sure to make a users post with these details 
> here shortly.

Thanks.  I could probably find the patch (or a patch) with a little more 
Googling.  Applying it is a different story.  As I said above, I don't have 
complete control of the server.  Changing the OS would take some finagling.

&g

RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

[Geoff Field]

> From: Ben Reser
> Sent: Friday, 8 November 2013 16:55 PM
> On 11/7/13 6:37 PM, Geoff Field wrote:
> > I'm just trying to bump the priority again, given our circumstances.
> 
> Consider it bumped. :)

Thanks Ben.  I noticed your post on the matter.

> > So is it just mod_dav*.so that's affected?
> 
> Correct, this is only applicable to DAV.  You won't see this 
> problem if you're using svnserve and it doesn't impact things 
> that aren't DAV related with respect to httpd.  In practice 
> this makes it generally specific to Subversion.

Understood.  In our case, SVN is the entire reason we have Apache running at 
all.  Our IT Department really favours the MS "solution".

>  Though I'm sure there's some people out there using 
> mod_dav_fs (presumably those people are the ones that wanted 
> the fix that triggered several problems for us).
> 
> > I agree.  Breaking/releasing locks is NOT a resolution.  
> Applying patches (or patched software) is.  Is there an easy 
> way to apply a patch on a Windows server with limited drive 
> space for extra tools such as compilers?
> 
> Building httpd on Windows is unfortunately not easy at this 
> time.

I suspected as much.  Oh well.

>  I'd suggest going with a binary produced by one of the 
> vendors.  I think several have already patched.  Mark 
> mentioned that Collab.Net's packages are patched.

I've downloaded those, too, but the installation hasn't "taken" yet.  I'll have 
to edit the httpd.conf a bit more carefully to make things work with it.  (At 
present, I'm getting an error 1, which I'm sure is due to a misconfiguration.  
I'll RTFM before posting any more about that.  Quite likely, I should have 
tried the vanilla install first, then modified to suit.)

>  Maybe one 
> of the other providers will chime in here that there's are 
> patched as well.
> 
> Putting my own corporate hat on for a moment here.  WANdisco 
> binaries that come with httpd should be patched as well.  I 
> need to ask the individual that builds them to verify for 
> sure.  If you find that they are not let me know and I'll see 
> that this changes.  You can find the WANdisco binaries here 
> for free download:
> http://www.wandisco.com/subversion/download

Thanks.

I've downloaded the WanDisco version and I'll try the installation on Monday.  
(It's past home time on a Friday here in South-Eastern Australia.)  If the 
WanDisco binary works better for me, I will probably not do any more work on 
the Collabnet update.  Either way, I'll let you know.

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: NOW RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

[Geoff Field]

> From: Ben Reser
> Sent: Saturday, 9 November 2013 4:30 AM
> 
> On 11/7/13 9:55 PM, Ben Reser wrote:
> > Putting my own corporate hat on for a moment here.  
> WANdisco binaries 
> > that come with httpd should be patched as well.  I need to ask the 
> > individual that builds them to verify for sure.  If you 
> find that they 
> > are not let me know and I'll see that this changes.  You 
> can find the WANdisco binaries here for free download:
> > http://www.wandisco.com/subversion/download
> 
> I have confirmed that the WANDisco binaries for Windows and 
> Solaris include httpd and have been patched.  Other platforms 
> do not include Apache httpd but use the one already on the 
> host OS/distribution.

Hi All,

After installing several different versions and fiddling around with various 
options in the configuration files, I ended up just copying the mod_dav*.so 
from the WANDisco modules directory to the working Apache directory.  
Everything now seems to work fine.

Copying locked directory trees is now transparent.

Thanks very much to Ben (and all the many others who responded).

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: Method not allowed exception

[Geoff Field]

Sorry for top-posting, but although Brane is right, he's not being as helpful 
as he could.

Stefano, I had pretty much the same issue.  A workaround is to only do actions 
(other than Commit) on unlocked working copies.  That is, before doing a copy 
(in particular), make sure all locks are released.

The fix that worked for me was to update the server.  I downloaded the Wandisco 
server binaries (which are patched with the fix to this issue) and then copied 
mod_dav*.so to the modules directory of the Apache installation that we have 
actually working.  (Ideally, I'd just install and run the Wandisco binaries, 
but with our configuration it was easiest to get working by just doing the 
copy.)

Regards,

Geoff



From: Branko Čibej
Sent: Friday, 15 November 2013 18:09 PM
To: users@subversion.apache.org
Subject: Re: Method not allowed exception


On 15.11.2013 07:47, Stefano Fraccaro wrote:


Il 14/11/2013 22:35, Ben Reser ha scritto: 


Can you elaborate what method you're seeing method not 
allowed with?  Or if you 
were running a svn client what command you were 
running? 


TortoiseSVN > SVN Checkout 



The one case where we made such a change that comes to 
mind is with LOCK.  LOCK 
per the RFC can lock files that don't exist (otherwise 
known as an unmapped url 
or null resources). 

http://webdav.org/specs/rfc4918.html#lock-unmapped-urls 
http://webdav.org/specs/rfc2518.html#rfc.section.7.4 

We only support this when SVNAutoversioning is turned 
on and return a method 
not allowed error if this isn't turned on.  We felt 
that the method not allowed 
error was the logical error to return. 

The other cases where we return method not allowed 
typically are cases where we 
don't allow that method on regular URLs unless 
auto-versioning is enabled. 




We have an apache installation with subversion modules ( 
http://webserver/ ). 
All our repositories are in svn subfolder ( 
http://webserver/svn/RepositoryName ) 
If I checkout the url 
'http://webserver/badname/RepositoryName', subversion 
return '405 Method not allowed' instead of '404 Url not found'. 


Unexpected HTTP status 405 Method Not Allowed on 
'/badname/RepositoryName' 
Additional errors: 
PROPFIND request on '/badname/RepositoryName' failed: 405 
Method not allowed 



I think you are mistaken, this error probably not returned by 
Subversion (since it's not configured on that location) but by the Apache HTTPd 
server itself. Most likely your server interprets the request as a PROPFIND on  
directory "badname" within the directory defined by the server configuration 
option  DocumentRoot. The default server configuration probably only allows GET 
requests on such paths; which makes a kind of sense, since the PROPFIND method 
is defined by the DAV protocol, not HTTP itself.

-- Brane


-- 
Branko Čibej | Director of Subversion 
WANdisco // Non-Stop Data 
e. br...@wandisco.com


- 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: Method not allowed exception

[Geoff Field]

> From: Ben Reser
> On 11/17/13 2:12 PM, Geoff Field wrote:
> > Sorry for top-posting, but although Brane is right, he's 
> not being as helpful as he could.
[snip]
> Your issue and the one he is having aren't similar at all.
> 
> He was trying to do a checkout against a URL that isn't 
> directed at Subversion.
>  Subversion uses HTTP methods that normally aren't typically 
> used by a web browser.  As a result Apache HTTPD rejected the 
> request by the Subversion client with a Method Not Allowed 
> (405) error rather than a Not Found (404) error as he was 
> expecting.  This is normal behavior of Apache httpd (though 
> perhaps we could improve our error message to help a user 
> realize this probably means they're using the wrong URL or 
> the server is misconfigured).
[snip]

I sit corrected.

Why am I not surprised that I got the wrong end of the stick? ;-)

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 to prevent casual browsing

[Geoff Field]

Hi Peter

> From: Peter Flynn
> Sent: Monday, 2 December 2013 1:40 AM
> 
> I have a number of svn repositories running under 
> Apache+subversion on CentOS6/64, with Submin to provide a web 
> GUI to manage them:
> 
>   server.name/svn/foo
>   server.name/svn/bar
>   server.name/svn/blort
> etc
> 
> All of them are private; all but one of them are single-user 
> (me) so that I can carry on working from any of my machines 
> in multiple locations. One of them is shared with colleagues 
> on a project: they all have read/write privs on that repo.

Are they separate projects or separate accesses to the same project?  You know, 
of course, that you can set up authz privileges to specific subdirectories?

> The URIs are not published or linked, and my colleagues are 
> all well aware of the need to keep their shared URI private. 
> But the requirement is that none of them must be open to 
> casual read access via a web browser, in case someone happen 
> to stumble upon or guess the URI.
> 
> I am having problems getting the access privs right, as they 
> keep causing "svn: E22: Not authorized to open root of 
> edit operation"
> during an svn up. However, in a long exchange with the very 
> helpful submin support
> (https://ssl.supermind.nl/collab/projects/submin/ticket/336) 
> we have failed to identify settings that work.

Not sure about this one.

> Currently the svn/conf/authz file says
> 
> > [groups]
> > dev = a,b,c,d,e,me
> > 
> > [foo:/]
> > @dev = rw
> > 
> > [bar:/]

For the private one, try adding the following line here:
* =
That turns off read and write access for everybody EXCEPT the explicitly-named 
members.  At least, it works that way for us.

> > me = rw
> > 
> > [blort:/]
> > me = rw
> 
> The Apache conf.d/subversion.conf says:
> 
> > 
> >DAV svn
> >SVNParentPath /var/lib/submin/svn
> > # removed GET from LimitExcept to prevent casual browsing
> >
> >   AuthType Basic
> >   AuthName "Authorization Realm"
> >   AuthUserFile /etc/svn.auth
> >   Require valid-user
> >
> > 
> 
> and svn.auth specifies a username:encryptedpassword pair for 
> each member of [groups] in the usual way.
> 
> 1. Browsing with a web browser causes a prompt for the 
> username/password as expected.
> 
> 2. An svn ci operation works fine.
> 
> 3. An svn up operation fails, and always causes an E22 error.
> 
> 4. Replacing the GET in the LimitExcept config allows svn up 
> to work without error, but allows casual browsing of the web 
> interface.
> 
> Is there a way to prevent the casual browsing while avoiding 
> the E22 error?

-- 
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: Upgrade SVN from version 1.5.6 (r36142) to 1.8.5

[Geoff Field]

Hi Guido,

> -Original Message-
> From: Stefan Sperling
> Sent: Friday, 14 February 2014 1:03 AM
> 
> On Thu, Feb 13, 2014 at 10:57:15AM -0200, Guido Larrain wrote:
> > Hello;
> > 
> > I'm planning to upgrade my SVN from version 1.5.6 (r36142) to 1.8.5 
> > and i wanna know if i need to do some "special" steps to 
> perform this.

Is that the client or the server?  If it's the client, you should have no 
problems.  The only potential problem will be if you have working copies on a 
shared drive (it's not recommended, but it happens) and other people who access 
these are using different versions.

If it's the server, you might need to upgrade any BDB repositories to FSFS.

Regardless, read the notes on the links that Stefan provided.

> > Thanks in advance!!
> > 
> > --
> > Guido
> 
> The most special step (most people don't seem to do this ;) 
> is to read the upgrade documentation in the release notes for 
> each intermediate release (1.6 to 1.8 in your case), which 
> document the special steps, if any, better than any 
> subscriber of this list could recite from memory.
> 
> http://subversion.apache.org/docs/release-notes/1.6.html#compatibility
> http://subversion.apache.org/docs/release-notes/1.7.html#compatibility
> http://subversion.apache.org/docs/release-notes/1.8.html#compatibility
> 
> If you still have questions after reading, feel free to ask.


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. 

SVN Development Tracking Methodologies and Tools

[Geoff Field]

This is a question for the SubVersion developers.

What tools and/or methods did you use for tracking the various tasks for 
developing SubVersion?  Was it just a bunch of emails, or did you use an issue 
tracker (or similar) for tasks?

If you've been involved in other open-source developments, how were they done 
from a project management perspective?

Just out of interest.

Thanks for any feedback.

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 Query about granting access

[Geoff Field]

> From: Daniel Shahaf
> Sent: Monday, 7 April 2014 18:13 PM
> 
> karthik kg wrote on Mon, Apr 07, 2014 at 17:40:54 +1000:
> > Repository name - TTN
> > Location on the server -
> > 
> > /apps/bss/SubVersion_Repository/TTN
> > 
> > 
> > I tired editing the 
> /var/opt/app/SubVersion_Repository/NTT/conf/auth 
> > file with below parameter for providing read only access to 
> the TTN repository.
> > 
> > 
> > [repository:/NTT]
> > 
> >   d389678 = 'r'

As well as what Daniel has quite rightly said, it looks like there's a space at 
the start of the line.  I seem to remember another message on this list 
commenting that spaces at the start of the line might not be a good idea.

Also, Daniel doesn't say it, but the repository name doesn't look right.  
Daniel's edited version should get your user authenticated correctly.

> > But even after changing the auth file, i can see i hav 
> write access to 
> > the user d389678.
> > 
> > My query is, is there any file that needs to be updated? if yes, 
> > kindly provide us the detailed view of the parameter that 
> needs to be 
> > updated on the file.
> 
> There isn't any other file, but you didn't edit that file correctly.
> 
> Don't use single quotes (') in the value.  It is not 
> guaranteed to work and may stop working in future versions.
> 
> I think you mean:
> 
> [TTN:/]
> d389678 = r
> 
>That is: the "/" path within the repository called "TTN".
> 
> If this doesn't work, please indicate whether you use 
> svnserve or httpd, and whether you use -r/--root (svnserve) 
> or SVNParentPath (httpd) and if so what path it is set to.

Good luck,

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 Query about granting access

[Geoff Field]

Hi Karthik,

Please ensure you reply to the whole group, as there are many people on the 
mailing list who are far more knowledgeable than I.  Also, the convention seems 
to be to use plain-text and to reply within/under the quoted text.

From: karthik kg  
Sent: Tuesday, 8 April 2014 15:11 PM
To: Geoff Field
Subject: Re: SVN Query about granting access


Hi Geoff, 

Thanks for the information. But still it didnt work out.

What result/message is the user actually seeing?

>From what I'm seeing, you're trying to give that specific user read-only 
>access, but they're getting read/write access.

Some of my following queries are based on Windows and might not apply on your 
platform:

Have they actually logged out and in again?

Have you restarted the httpd daemon after reconfiguring?  (This shouldn't be 
necessary, but it could be worth a try.)

Do you grant global read/write access to that repository at all?


My repository uses httpd and the SVN path in Subversion.conf is 
"SVNPath /var/opt/app/photon/repository/NTT"

That's a start.  Daniel also asked for: "whether you use -r/--root (svnserve) 
or SVNParentPath (httpd) and if so what path it is set to."

Those more knowledgeable about using httpd on a *nix platform (I'm using 
Windows at present) will probably be looking for a more complete extract from 
the Subversion.conf file about now.

Regards,

Geoff

On Tue, Apr 8, 2014 at 9:03 AM, Geoff Field  
wrote:


> From: Daniel Shahaf
> Sent: Monday, 7 April 2014 18:13 PM

>
> karthik kg wrote on Mon, Apr 07, 2014 at 17:40:54 +1000:
> > Repository name - TTN
> > Location on the server -
> >
> > /apps/bss/SubVersion_Repository/TTN
> >
> >
> > I tired editing the
> /var/opt/app/SubVersion_Repository/NTT/conf/auth
> > file with below parameter for providing read only access to
> the TTN repository.
> >
> >
> > [repository:/NTT]
> >
> >   d389678 = 'r'


As well as what Daniel has quite rightly said, it looks like 
there's a space at the start of the line.  I seem to remember another message 
on this list commenting that spaces at the start of the line might not be a 
good idea.

Also, Daniel doesn't say it, but the repository name doesn't 
look right.  Daniel's edited version should get your user authenticated 
correctly.


> > But even after changing the auth file, i can see i hav
> write access to
> > the user d389678.
> >
> > My query is, is there any file that needs to be updated? if 
yes,
> > kindly provide us the detailed view of the parameter that
> needs to be
> > updated on the file.
>
> There isn't any other file, but you didn't edit that file 
correctly.
>
> Don't use single quotes (') in the value.  It is not
> guaranteed to work and may stop working in future versions.
>
> I think you mean:
>
> [TTN:/]
> d389678 = r
>
>That is: the "/" path within the repository called "TTN".
>
> If this doesn't work, please indicate whether you use
> svnserve or httpd, and whether you use -r/--root (svnserve)
> or SVNParentPath (httpd) and if so what path it is set to.


Good luck,

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 pr

RE: SVN Query about granting access

[Geoff Field]

From: karthik kg
Sent: Wednesday, 9 April 2014 13:17 PM


Hi Geoff, 


Apologies for replying to you. Please find my comments fro your queries 
below.

Replying directly to me is not a problem, really.  What might be a problem is 
that I don't know as many of the answers as some of the other contributors to 
this mailing list.

What result/message is the user actually seeing?  I'm facing No ERROR 
at the moment.

Fair enough.  From the description, that's what I'd expect.

From what I'm seeing, you're trying to give that specific user 
read-only access, but they're getting read/write access. Yes, That's right. 
Even post changing the user settings, i m getting read-write access for that 
user(d389678)

Some of my following queries are based on Windows and might not apply 
on your platform: Oh, anyway my platform is LINUX

I thought it might have been, but it's worth being sure.  What specific version?

Have they actually logged out and in again? Yes, Tried

Have you restarted the httpd daemon after reconfiguring?  (This 
shouldn't be necessary, but it could be worth a try.) Yes Tried.

Do you grant global read/write access to that repository at all? Not 
sure, about this. Can you please tell me where this param value specified?

In your Subversion.conf file, there could be a line - most likely related to 
that repository - that says something like:

* = rw

Alternatively, you could have something like this to control global access:

[/]
* = rw

If there's a line like that in there, it's possible it will override the 
individual user settings.  To make it global read-only, simply change it to:

* = r

Of course, I'm making a lot of assumptions here, but that's what works for us.  
We've been known to make specific repositories private in our configuration by 
saying (for that repository):

* =

I'm not totally convinced it will work, since the individual settings seem to 
override the global ones.  More knowledgeable heads than mine might have more 
of a clue.


Having said all this, one has to ask if restricting that user's access is 
strictly necessary.  Given that SVN logs all writes and changes and that 
everything can be reversed, is it really such a huge risk?

On the other hand, of course, there's the learning exercise for working out how 
to set the configuration file up.

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: Moving a repository with svn:externals using absolute paths (URLs)

[Geoff Field]

From: Nico Kadel-Garcia

On Wed, Jun 18, 2014 at 9:32 AM, Brisset, Nicolas 
mailto:nicolas.bris...@airbus.com>> wrote:
Hi,
We've been using svn successfully for years on a server, and now have to 
migrate to a new one. We are hit by the known issue of svn:externals containing 
absolute paths to the repo to be moved, since we started with versions <1.5 
without support for relative URLs.
We've been researching how to properly do this, knowing that we handle 
certified SW on that server, so losing data or corrupting the repo is not 
allowed, and we want to be able to go back in time and checkout an old state at 
any time.
We've experimented the svndumptool (http://svn.borg.ch/svndumptool/) referenced 
for instance in this post:
http://stackoverflow.com/questions/204616/how-to-migrate-all-urls-in-svnexternals-properties-across-a-repository
It seems to be the only tool doing what we want, and it apparently works, but 
before doing the change on the production repo we'd like to know what 
experiences there are with this tool, and if  it's safe to use - or if there is 
a better alternative.
Thanks for your feedback if you have any experience with this,
  Nicolas
Hi Nicolas,

We upgraded from 1.2 to 1.8 in one fell swoop.  We don't use externals, which 
made things easier.  However, most of our 1.2 repositories were in BDB format, 
which off-the-shelf Windows binaries of 1.8 don't handle.  (I am somewhat 
averse to trying to recompile for Windows, as that would entail finding and 
setting up the correct compilation environment for it - too much like work.)

I wrote a batch file to do a dump, reload and rename on each repository.  
Basically, the old repositories were left in place, but with the name changed 
to append "_BDB" and the re-loaded repositories in FSFS format run live.  Full 
history now lives in both sets of repositories, with the BDB versions retained 
in case we ever need to go back and double-check.


The simple answer I'd recommend is "don't". The amount of time you are going to 
spend trying to cross migrate old build environments is expensive, fragile, and 
requires polluting your history to generate a new, and misleading one, pointing 
to the correct SVN server.

Set aside the legacy configuration, incompatible as it is with modern 
"relative" URL's, for reference and log analysis only. Keep it pristine, and 
don't muck with the history. Bring only the relevant components to your new 
server, on a scheduled cutover date, and take the opportunity to discard bulky 
binaries and branches and logs and security sensitive debris with the move to a 
new server with a new URL. Drop a README.txt in place on the new server 
pointing to the old, legacy repository, and kick it aside.

This is basically what we did, but without mucking about to edit dump files, 
etc.  As Nico says, keep the originals pristine.  Disk space is cheap (although 
backup on alternative storage might not be).
If your employers or clients cannot accept this, create migration branches, and 
tags as soon as you do the replication, with the safe new "svn:externals" 
settings. This is much safer than manipulating the old logs: once you get into 
manipulating logs, it's like cross-breeding puppies from the same litter: you 
may get the champion you want, but the practice can also lead to a lot 
disasters which will be blamed on the editing, even if it's not really the 
source of the problem.
There's also the point that any editing you do is (a) prone to human error and 
(b) likely to consume large amounts of your time.

In our duplication effort, we also set all the permissions on the old 
repositories to read-only, to limit the chances of cross-contamination.

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: Moving a repository with svn:externals using absolute paths (URLs)

[Geoff Field]

> From: Nico Kadel-Garcia
> On Wed, Jun 18, 2014 at 9:35 PM, Geoff Field wrote:
> 
> > In our duplication effort, we also set all the permissions 
> > on the old repositories to read-only, to limit the chances
> > of cross-contamination.

Just to be clear, I'm not talking about the FILE permissions
here, merely the SVN access permissions.  To be really clear,
the original repositories are only being kept as a paranoia
measure, just in case our customers (or legal representatives)
require unsullied history at some indefinite time in the future.

> > Regards,
> >
> > Geoff
> 
> This. So much this. When people want to keep, and keep 
> cross-merging, the contents of multiple distinct live 
> repositories while work is being replicated and cross-merged 
> from all of them, it's usually time to look for a new job: 

The vast majority of those repositories have been unused for
some years, and our development team is (now) small enough so
that I can guarantee there was no work proceeding on any of
them.  Naturally, I also shut down SubVersion while it was in
progress, just in case.

> someone has been excited by the shiny tools and forgotten 

Ooh, shiny ... What were we talking about? ;-)

> "source control is a 24x7, it must *work* and work *every 
> time*" resource.

Quite right.  That's why our repositories are on a RAID system
(now a SAN, actually) with regular backup (including off-site).

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:

[Geoff Field]

Does this user actually post anything useful, or is it a spammer who should be 
removed from the list?





From: Jacky wong [mailto:wjacky...@gmail.com] 
Sent: Monday, 21 July 2014 14:12 PM
To: users@subversion.apache.org
Subject: 



-- 
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 command line client 1.8.8 - Error: file name or extension is too long

[Geoff Field]

> On Fri, Sep 12, 2014 at 11:29:37AM +0200, 
> milan_plan...@swissre.com wrote:
> > Dear team,
> > 
> > I tried to commit my changes with following error message:
> > 
> > Error:Cannot run program 
> "C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe" (in 
> > directory
> > 
> "C:\Users\S3F96Q\work\sources\g10ct\SR_G10_CT\modules\sr-g10-c
> t-batch-xd\src\main\resources"): 
> > CreateProcess error=206, The filename or extension is too long
> > 
> > This file in its path is far away from the longest name in 
> project and 
> > I only changed the content of its file (did not changed the path or 
> > file name). This error prevents me to commit my changes. I 
> also tried 
> > to checkout it from scratch, so that path changed to:
> > 
> C:\work\sources\g10ct\SR_G10_CT\modules\sr-g10-ct-batch-xd\src\main\re
> > sources,
> > but id did not help.
> > 
> > Then I tried to commit changes in chunks (I did not change 
> any path or 
> > file name), which finally worked. I had 285 files to commit.
> > 
> > 1. Is it bug? At least message does not correspond to real error 2. 
> > Can it be configurable (the max file count to commit or 
> some buffer)?
> > (How?)
> > 3. Is it fixed in some newer version?
> > 
> > Thank you
> > With regards
> > 
> > Milan Plancik
> 
> IIRC this is a limitation of windows.

Yes, there is such a limitation of Windows.  I've encountered it before in 
other applications.  There's a known issue with paths over 260 characters long, 
INCLUDING the drive letter, the colon AND the terminating NUL.  See this MSDN 
article:
http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath

If you prepend the string '\\?\' to the path, it's meant to allow 32,767 
Unicode characters of path name.  We've found, however, that some languages 
(such as National Instruments' LabVIEW up to version 8.6 at least) don't allow 
this.

There are two approaches available in this case:
1) Shorten your path names.
2) Use the DOS subst command to create a new virtual drive starting at an 
appropriate place in the tree (preferably the directory where the .svn 
directory resides).  It would be something like "SUBST Z: 
C:\work\sources\g10ct"  When you're done, you can then do "SUBST Z: /D" to 
delete it.

However, please note that Milan finally mannaged to commit all the files by 
doing them in smaller batches.  That would seem to indicate some other issue.

> Passing absolute paths on the command line should work around it.

Probably not, given what I've just discussed.
 
> BTW, please try to avoid posting disclaimers like the one 
> below to public mailing list. See 
> http://producingoss.com/en/communications.html#face

Some of us are subject to the whims and caprices of a corporate IT department 
(and their bosses).  I know I am.  We can't avoid the disclaimers if we're 
using our work emails.

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 command line client 1.8.8 - Error: file name or extension is too long

[Geoff Field]

> On Mon, Sep 15, 2014 at 09:38:29AM +1000, Geoff Field wrote:
> > However, please note that Milan finally mannaged to commit 
> all the files by doing them in smaller batches.  That would 
> seem to indicate some other issue.
> 
> What were the commands he typed which worked?

Sorry Stefan, but I'm the wrong person to ask about this.  However, from 
Milan's original post:
"Then I tried to commit changes in chunks (I did not change any path or file 
name), which finally worked. I had 285 files to commit."

Note that he also said: "This file in its path is far away from the longest 
name in project..."
This implies that files with longer pathnames successfully committed.  However, 
it's up to Milan to confirm or deny this.

> There are references to absolute paths working around the 
> problem in the archives:
> http://svn.haxx.se/users/archive-2005-02/1088.shtml
> 
> There are also posts that seem to contradict this theory:
> http://svn.haxx.se/dev/archive-2004-10/1482.shtml
> 
> I don't use windows so I can't verify any of this myself.

Part of the problem is that the rules very much depend on which version of 
Windows is being used.  Back in 2004/2005, XP was the bees' knees.  (Mind you, 
I'm typing this on a machine that's still running XP.)  Nowadays, things are 
somewhat different.  The next OS produced by MS was a 64-bit one, with all 
sorts of rule (and, of course, API) changes.

It would help if Milan told us more details, such as the exact platform (which 
Windows?) and the exact commands entered.

We know the SVN version from this: "C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe"

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.