Re: [PATCH] Fix non-ASCII cmdline options in non-UTF-8 locales

Julian Foad wrote on Fri, Apr 26, 2013 at 00:32:32 +0100: > Some other arguments, including '--native-eol', are not converted > before testing for valid values, and the valid values are always > ASCII.  This is OK, if we assume an ASCII subset.  That's probably > safe, as [1] indicates that all com

Auto-props and case-insensitive non-ASCII matching

Just to make sure this thought of Stefan's doesn't get forgotton: Quoting from the email thread "log --search test failures on trunk and 1.8.x", : "If we're going to say that CASE_BLIND should not be used, I'd like to point out that the autoprop

[PATCH] Fix non-ASCII cmdline options in non-UTF-8 locales

While reviewing r1475724 "Fix changelist filtering when --changelist values aren't UTF8", I noticed we also fail to convert some other command-line options to UTF-8. The attached patch addresses:   --old, --new:     Fix usage of non-ASCII paths. It looked for the wrong file and so was     unus

RE: svn commit: r1470904 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

> -Original Message- > From: Paul Burba [mailto:ptbu...@gmail.com] > Sent: donderdag 25 april 2013 21:38 > To: Philip Martin > Cc: Bert Huijben; Subversion Development > Subject: Re: svn commit: r1470904 - > /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql > > On Thu, Apr 25, 2013

Re: svn commit: r1470904 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

On Thu, Apr 25, 2013 at 1:05 PM, Philip Martin wrote: > Paul Burba writes: > >>> # We expect the repos root property to show up here! >>> >>> 1.9.0-dev@1475809>svn pg svn:auto-props . --show-inherited-props >>> >>> 1.9.0-dev@1475809> > > Is that expected? The inherited property is not in the 1.7

Re: svn commit: r1470904 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

Paul Burba writes: >> # We expect the repos root property to show up here! >> >> 1.9.0-dev@1475809>svn pg svn:auto-props . --show-inherited-props >> >> 1.9.0-dev@1475809> Is that expected? The inherited property is not in the 1.7 working copy. Do you expect upgrade to contact the repository an

Re: svn commit: r1470904 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

On Thu, Apr 25, 2013 at 11:58 AM, Paul Burba wrote: > On Wed, Apr 24, 2013 at 6:34 PM, Bert Huijben wrote: >> >> >>> -Original Message- >>> From: Bert Huijben [mailto:b...@qqmail.nl] >>> Sent: donderdag 25 april 2013 00:14 >>> To: 'Paul Burba'; 'Subversion Development' >>> Subject: RE: sv

Re: svn commit: r1470904 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

On Wed, Apr 24, 2013 at 6:34 PM, Bert Huijben wrote: > > >> -Original Message- >> From: Bert Huijben [mailto:b...@qqmail.nl] >> Sent: donderdag 25 april 2013 00:14 >> To: 'Paul Burba'; 'Subversion Development' >> Subject: RE: svn commit: r1470904 - >> /subversion/trunk/subversion/libsvn_wc

Re: Issue #2485 - Authz repository matching is both case sensitive and case insensitive

On 04/25/2013 09:20 AM, Julian Foad wrote: > Issue #2485 "Authz repository matching is both case sensitive and case > insensitive" is still open. It is about case sensitivity in the paths in > authz files. (I'm looking at it only because I found it while searching > for issues about authz user na

Re: Bug in conflict summary after partial resolution

I (Julian Foad) wrote: > I (Julian Foad) wrote on 2013-04-15: >> Mattias Engdegård wrote: >>> If a file has both text and property conflicts, only resolving one of >>> them leads to an incorrect conflict summary message. [...] > The solution I'm implementing is to make the conflict resolver callba

Issue #2485 - Authz repository matching is both case sensitive and case insensitive

Issue #2485 "Authz repository matching is both case sensitive and case insensitive" is still open.  It is about case sensitivity in the paths in authz files.  (I'm looking at it only because I found it while searching for issues about authz user names; this issue contains a comment about there b

Re: Case sensitivity in authz files

On Thu, Apr 25, 2013 at 9:13 AM, Branko Čibej wrote: > mArk, if you'd taken the time to read the thread, you would not write > such nonsense. Go look up Philip's examples of how things are broken now. I understood how things are broken now. The scenarios are contrived and meaningless. That sai

Re: Case sensitivity in authz files

On 25.04.2013 15:07, Mark Phippard wrote: > On Thu, Apr 25, 2013 at 9:04 AM, Mark Phippard wrote: >> On Thu, Apr 25, 2013 at 8:37 AM, Philip Martin >> wrote: >>> Julian Foad writes: >>> I am only questioning the assignment of a 1.8.0 "release blocker" milestone. >>> That was simply bec

Re: Case sensitivity in authz files

On Thu, Apr 25, 2013 at 9:04 AM, Mark Phippard wrote: > On Thu, Apr 25, 2013 at 8:37 AM, Philip Martin > wrote: >> Julian Foad writes: >> >>> I am only questioning the assignment of a 1.8.0 "release blocker" >>> milestone. >> >> That was simply because Branko suggested he was targeting 1.8.0. W

Re: Case sensitivity in authz files

On Thu, Apr 25, 2013 at 8:37 AM, Philip Martin wrote: > Julian Foad writes: > >> I am only questioning the assignment of a 1.8.0 "release blocker" >> milestone. > > That was simply because Branko suggested he was targeting 1.8.0. We > have to decide now because I don't think we would put this in

Re: Case sensitivity in authz files

Julian Foad writes: > I am only questioning the assignment of a 1.8.0 "release blocker" > milestone. That was simply because Branko suggested he was targeting 1.8.0. We have to decide now because I don't think we would put this into a minor release (the last case-sensitivity change went into 1.

Re: Case sensitivity in authz files

On 25.04.2013 14:28, Julian Foad wrote: > Philip Martin wrote: >> Philip Martin writes: >>> Julian Foad writes: So what exactly is broken, behaviour-wise? Is authorization done with case-insensitive username checking in the server, and the "svnauthz" tool is broken in that it fail

Re: Case sensitivity in authz files

Philip Martin wrote: > Philip Martin writes: >> Julian Foad writes: >>> So what exactly is broken, behaviour-wise?  Is authorization done with >>> case-insensitive username checking in the server, and the "svnauthz" >>> tool is broken in that it fails to do case-insensitive matching of >>> userna

Re: Case sensitivity in authz files

Philip Martin writes: > Julian Foad writes: > >> So what exactly is broken, behaviour-wise?  Is authorization done with >> case-insensitive username checking in the server, and the "svnauthz" >> tool is broken in that it fails to do case-insensitive matching of >> usernames?  Or something else?

Re: Case sensitivity in authz files

Julian Foad writes: > So what exactly is broken, behaviour-wise?  Is authorization done with > case-insensitive username checking in the server, and the "svnauthz" > tool is broken in that it fails to do case-insensitive matching of > usernames?  Or something else? The tool and the server do the

Re: Case sensitivity in authz files

On 25.04.2013 13:39, Julian Foad wrote: > Philip Martin > >> Branko Čibej writes: >> >>> I also propose, in advance, that we include this change in 1.8. It >>> should be relatively non-invasive as far as code is concerned, but of >>> course we'll have to yell loudly in the release notes about t

Re: Case sensitivity in authz files

Philip Martin > Branko Čibej writes: > >> I also propose, in advance, that we include this change in 1.8. It >> should be relatively non-invasive as far as code is concerned, but of >> course we'll have to yell loudly in the release notes about the changed >> behaviour. > > I've raised http

Re: svn commit: r1471717 - /subversion/trunk/subversion/svnadmin/svnadmin.c

Ivan Zhakov wrote on Thu, Apr 25, 2013 at 13:29:05 +0400: > On Thu, Apr 25, 2013 at 3:14 AM, Daniel Shahaf > wrote: > > On IRC you also made a point about the "Config files" output (prints the > > path to DB_CONFIG or to fsfs.conf). Do you think it should be removed > > from 'svnadmin info'? Fr

Re: Case sensitivity in authz files

Branko Čibej writes: > I also propose, in advance, that we include this change in 1.8. It > should be relatively non-invasive as far as code is concerned, but of > course we'll have to yell loudly in the release notes about the changed > behaviour. I've raised http://subversion.tigris.org/issues

Re: svn commit: r1471717 - /subversion/trunk/subversion/svnadmin/svnadmin.c

On Thu, Apr 25, 2013 at 3:14 AM, Daniel Shahaf wrote: > Ivan Zhakov wrote on Thu, Apr 25, 2013 at 02:58:05 +0400: >> On Thu, Apr 25, 2013 at 2:01 AM, wrote: [...] > > *nod*. Is that your preference or the project-agreed style? > It's not project agreed style, but I remember some discussions on