E200033 error for "svn copy" on Windows due to case sensitive pathnames (for SVN 1.7)

2012-01-18 Thread Niko Wilbert
Hi, using "svn copy" on Windows 7 with SVN 1.7.1 (1.7.1-SlikSvn-1.7.1-X64) I got the following error message: E200033: database is locked, executing statement 'RELEASE s1' I pinned it down to a case sensitivity issue with the pathnames. The following batch script reproduces the error: mkdir

RE: E200033 error for "svn copy" on Windows due to case sensitive pathnames (for SVN 1.7)

2012-01-18 Thread Bert Huijben
> -Original Message- > From: niko.wilb...@googlemail.com [mailto:niko.wilb...@googlemail.com] > On Behalf Of Niko Wilbert > Sent: woensdag 18 januari 2012 13:02 > To: dev@subversion.apache.org > Subject: E200033 error for "svn copy" on Windows due to case sensitive > pathnames (for SVN 1.

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Julian Foad
Hi Paul. Paul Burba wrote: > Julian Foad wrote: >> I (Julian Foad) wrote: > I think I understand now.  Your patch works fine when the only cyclic > merges are done via reintegrate (i.e. r24). [...] > I thought you were going to tackle more complex reflective merge > cases, such as this example:

Re: svn commit: r1232634 - /subversion/branches/ev2-export/subversion/libsvn_client/export.c

2012-01-18 Thread Hyrum K Wright
On Tue, Jan 17, 2012 at 11:10 PM, Daniel Shahaf wrote: > hwri...@apache.org wrote on Tue, Jan 17, 2012 at 23:04:32 -: >> Author: hwright >> Date: Tue Jan 17 23:04:32 2012 >> New Revision: 1232634 >> >> URL: http://svn.apache.org/viewvc?rev=1232634&view=rev >> Log: >> On the ev2-export branch:

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Julian Foad
I (Julian Foad) wrote: [] > What do we want in this case?  The options are basically: > >   (1) try to merge (as we do now), despite knowing it will conflict; >   (2) skip r11 (not usually good in this kind of case); Two clarifications: The options I'm listing are all the options that I thi

Re: Why no "default" editor in Ev2?

2012-01-18 Thread Hyrum K Wright
On Tue, Jan 17, 2012 at 3:41 PM, C. Michael Pilato wrote: > On 01/17/2012 04:31 PM, Hyrum K Wright wrote: >> I'm working at experimenting with a simple Ev2 consumer implementation >> (see the ev2-export branch).  In doing so, I've once again noticed >> that anybody implementing such a consumer has

Re: svn commit: r1232614 - /subversion/branches/ev2-export/subversion/libsvn_client/export.c

2012-01-18 Thread Hyrum K Wright
On Tue, Jan 17, 2012 at 11:05 PM, Daniel Shahaf wrote: > hwri...@apache.org wrote on Tue, Jan 17, 2012 at 22:32:54 -: >> Author: hwright >> Date: Tue Jan 17 22:32:53 2012 >> New Revision: 1232614 >> >> URL: http://svn.apache.org/viewvc?rev=1232614&view=rev >> Log: >> On the ev2-export branch:

Re: svn info --xml malformed XML on error

2012-01-18 Thread Steven R. Loomis
Daniel, I'm not asking to change the error condition. I guess I would prefer to emit an error in XML format, or to emit no XML at all. It doesn't seem like an "unexpected fatal error", especially because svnversion doesn't return an error. Perhaps, '/tmp' is not a working copy. Thanks, Stev

Re: svn info --xml malformed XML on error

2012-01-18 Thread Daniel Shahaf
An error may happen at any point during processing. Agreed that if an error pertains to one specific target it'd be sane to render the error as XML within that target's scope and render the remaining targets normally. But if there is a more global error (say: internal assertion triggered) I think

What's the plan for 1.8?

2012-01-18 Thread Hyrum K Wright
It's been over 3 months since 1.7 (6 months since the branch), we've had some good feedback, as well as a bit of bugs reported and fixed. I've heard various "estimates" about 1.8, but I'd like to have a brief discussion about what people's expectations are, both surrounding content and date. I kno

Re: svn info --xml malformed XML on error

2012-01-18 Thread Steven R. Loomis
Agreed, errors can happen at any point- but this particular error hardly seems like an unexpected internal fatal assertion, especially given svnversion. Thanks, not urgent for me, just surprising. -s On 01/18/2012 09:25 AM, Daniel Shahaf wrote: An error may happen at any point during process

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Paul Burba
On Wed, Jan 18, 2012 at 8:45 AM, Julian Foad wrote: > Hi Paul. > > Paul Burba wrote: > >> Julian Foad wrote: >>> I (Julian Foad) wrote: >> I think I understand now.  Your patch works fine when the only cyclic >> merges are done via reintegrate (i.e. r24). > > [...] > >> I thought you were going to

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Julian Foad
Paul Burba wrote: > Julian Foad wrote: >> I describe the idea of "logical changes" in >> . > > Most of the ideas there make sense, though I'm a bit foggy as to how > the mergeinfo format will change and how we'll migrate existing > repositor

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Branko Čibej
On 18.01.2012 14:45, Julian Foad wrote: >> A@1---r4---r5---r6---r7r11---> >> |\ ^ | >> | \| | >> | \ reintegrate | >> | V

Re: svnrdump on path deleted in HEAD (a different issue from my previous mail)

2012-01-18 Thread Neels J Hofmeyr
issue #4100 http://subversion.tigris.org/issues/show_bug.cgi?id=4100 On 01/17/2012 09:39 PM, C. Michael Pilato wrote: > On 01/17/2012 12:30 PM, Neels J Hofmeyr wrote: >> I can rdump single revisions of a path deleted in HEAD, but a revision range >> over the same two revisions fails: > > [...] >

Re: svnrdump with subpath and revision range has strange Node-paths

2012-01-18 Thread Neels J Hofmeyr
issue #4101 http://subversion.tigris.org/issues/show_bug.cgi?id=4101 On 01/17/2012 09:40 PM, C. Michael Pilato wrote: >> The first dumped revision's Node-paths are all relative to >> .../contrib/server-side; the next revision's Node-path is relative to ^/: >> >> [[[ >> Node-path: fsfsfixer >> [...

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Julian Foad
Branko Čibej wrote: > On 18.01.2012 14:45, Julian Foad wrote: >>> A@1---r4---r5---r6---r7r11---> >>>   |\                                    ^          | >>>   | \                                   |          | >>>   |  \                              reintegrate    |

Re: [RFC] Server Dictated Configuration

2012-01-18 Thread Paul Burba
On Tue, Jan 17, 2012 at 5:02 PM, Johan Corveleyn wrote: > On Tue, Jan 17, 2012 at 8:55 PM, Paul Burba wrote: >> On Tue, Jan 17, 2012 at 8:33 AM, Johan Corveleyn wrote: >>> On Tue, Jan 17, 2012 at 12:51 AM, Paul Burba wrote: >>> >>> [...] >>> We could chose to make things simple and follow

Re: Implicit keep-alive after reintegrate merge

2012-01-18 Thread Branko Čibej
On 18.01.2012 23:37, Julian Foad wrote: > Branko Čibej wrote: > >> On 18.01.2012 14:45, Julian Foad wrote: A@1---r4---r5---r6---r7r11---> |\ ^ | | \ | | | \

Re: [RFC] Server Dictated Configuration

2012-01-18 Thread Johan Corveleyn
On Thu, Jan 19, 2012 at 12:23 AM, Paul Burba wrote: > On Tue, Jan 17, 2012 at 5:02 PM, Johan Corveleyn wrote: [ ... ] >> Which makes me wonder: how will we discern inheritable props from >> normal ones? Merely saying that the svn:conf: namespace (for instance) >> means that it's always inherita

Re: svn info --xml malformed XML on error

2012-01-18 Thread Daniel Shahaf
Well, yes, but backwards compatibility means that we have to keep it returning an error ($? != 0 and stderr != ""), or we'll break everyone else's scripts. If you have a suggested change that is backwards compatible, we'd love to hear it. Steven R. Loomis wrote on Wed, Jan 18, 2012 at 10:27:45 -0

Re: svn info --xml malformed XML on error

2012-01-18 Thread Steven R. Loomis
My suggested change is as follows. Besides the current output (including the unterminated ""), additionally output (on stdout): '/tmp' is not a working copy. That provides some information in the xml rather than just failure. -s On 01/18/2012 05:02 PM, Daniel Shahaf wrote: Well, yes, but b

Re: svn info --xml malformed XML on error

2012-01-18 Thread Daniel Shahaf
That would also imply proceeding to the next target, right? 'svn info --xml /tmp /etc' In short --- +1 to filing this as a feature request in the issue tracker --- but I think there's seom work to be done on defining the new behaviour more precisely. Unfortunately I won't have the time for that