Re: 'svn auth' treats patterns as paths

I'll mention a few more suggestions about improvimg the 'svn auth' UI. Daniel Shahaf wrote on 28 June: > 'svn auth' URL-escapes and path-canonicalizes the pattern, which breaks some > use-cases. [...] > % $svn auth " ASF Committers" > DBG: Pattern 0 is '%3chttps://svn.

Mergeinfo property diff regression

'svn diff' describes svn:mergeinfo property diffs as "Merged ..." or "Reverse merged..." rather than using the unified diff output style that it uses for other property values. With Subversion 1.8.9: [[[ $ svn propget -rBASE svn:mergeinfo A; svn propget svn:mergeinfo A /trunk:10-15,20-25 /trunk

Re: Mergeinfo property diff regression

On Thu, Jul 03, 2014 at 04:13:54PM +0100, Julian Foad wrote: > 'svn diff' describes svn:mergeinfo property diffs as "Merged ..." or "Reverse > merged..." rather than using the unified diff output style that it uses for > other property values. > > With Subversion 1.8.9: > > [[[ > $ svn propget

Re: Mergeinfo property diff regression

Stefan Sperling wrote: > On Thu, Jul 03, 2014 at 04:13:54PM +0100, Julian Foad wrote: >> With Subversion 1.8.9: >> [[[ >> Modified: svn:mergeinfo >>    Merged /trunk:r16-18 >> ]]] >> >> With Subversion trunk the last part of the output changes to: >> >> [[[ >> Modified: svn:mergeinfo >> ## -0,0 +

Diff of svn:mergeinfo -- explicit vs. inherited mergeinfo

Our mergeinfo diffing (in 'svn diff') is quite broken with regard to inherited mergeinfo. Starting with a directory 'A' having mergeinfo   /trunk:16-18 if I do a subtree merge of /trunk/B:20 into A/B, then A/B gets a new svn:mergeinfo property with this value:   /trunk/B:16-18,20 That is, th

Move tracking -- creating a commit editor & Ev1 conversion shims

On the 'move-tracking-2' branch I have checked in an API sketch for a move-tracking commit editor API. (It contains two alternative designs in one, side by side, in fact.) I've called it "svn_editor3_t" (Ev3 for short) for the time being, not wanting to rip out or change the current "Ev2" just

Re: Move tracking -- creating a commit editor & Ev1 conversion shims

On 03.07.2014 19:34, Julian Foad wrote: > On the 'move-tracking-2' branch I have checked in an API sketch for a > move-tracking commit editor API. (It contains two alternative designs in one, > side by side, in fact.) > > I've called it "svn_editor3_t" (Ev3 for short) for the time being, not >

Re: Move tracking -- creating a commit editor & Ev1 conversion shims

Branko Čibej wrote: > Whilst node-specific addressing is acceptable on the server side, and perhaps even in the RA layer (perhaps with node IDs wrapperd in entry props and therefore stored in the wc.db), I'd really not want to expose node IDs to the client API, or make them visible to

svn rm $URI mangles the commit-message-template

1.6 on ubuntu precise gets this right, 1.8 on trusty gets it wrong, the following repro script is from trusty: $ mkdir svnrmbug $ cd svnrmbug /home/eichin/tmp/svnrmbug $ svnadmin create repo $ U=file://$(pwd)/repo $ svn mkdir --parents -m 'base' $U/{trunk,branches,tags,branches/me,tags/me} Commit

New help section 'Global Options'?

Currently, the global options are displayed on many svn help topics, and that's an extra 16 lines at the end, which makes the actual help info that is sought scroll off the screen, and it's not information that always needed. What do you think about moving the global options to their own help sect

Re: New help section 'Global Options'?

On 7/3/14 12:21 PM, Gabriela Gibson wrote: > Currently, the global options are displayed on many svn help topics, and > that's > an extra 16 lines at the end, which makes the actual help info that is sought > scroll off the screen, and it's not information that always needed. > > What do you thin

Re: Mergeinfo property diff regression

On Thu, Jul 03, 2014 at 05:27:00PM +0100, Julian Foad wrote: > Stefan Sperling wrote: > > On Thu, Jul 03, 2014 at 04:13:54PM +0100, Julian Foad wrote: > >> With Subversion 1.8.9: > >> [[[ > >> Modified: svn:mergeinfo > >>    Merged /trunk:r16-18 > >> ]]] > >> > >> With Subversion trunk the last pa

Re: svn rm $URI mangles the commit-message-template

On Thu, Jul 03, 2014 at 02:59:30PM -0400, Mark Eichin wrote: > $ cat svn-commit.tmp > > --This line, and those below, will be ignored-- > > Dfile:///home/eichin/tmp/svnrmbug/repo/bugbranch > > Note specifically the URI to be deleted. (Ironically, I think it really > *does* get ignored, a co

Re: svn rm $URI mangles the commit-message-template

On 7/3/14 2:16 PM, Stefan Sperling wrote: > Thanks for your report. > > This is definitely not intentional. I can reproduce this on 1.8.x but not > on trunk. Not sure yet when it was fixed on trunk. This was resolved by my commit in r1591123. It's currently nominated for backport in the 1.8.x ST

Re: svn rm $URI mangles the commit-message-template

On 7/3/14 2:50 PM, Ben Reser wrote: > This was resolved by my commit in r1591123. It's currently nominated for > backport in the 1.8.x STATUS file and is currently missing one vote (stsp: > hint > hint). I probably should have mentioned this is a regression that started in 1.7.9, so there's also

Re: 'svn auth' treats patterns as paths

Julian Foad wrote on Thu, Jul 03, 2014 at 13:51:49 +0100: > I'll mention a few more suggestions about improvimg the 'svn auth' UI. > > Daniel Shahaf wrote on 28 June: > > > 'svn auth' URL-escapes and path-canonicalizes the pattern, which breaks some > > use-cases. > [...] > > % $svn auth "

Re: svn rm $URI mangles the commit-message-template

Mark Eichin wrote on Thu, Jul 03, 2014 at 14:59:30 -0400: > 1.6 on ubuntu precise gets this right, 1.8 on trusty gets it wrong, the > following repro script is from trusty: > > $ mkdir svnrmbug > $ cd svnrmbug > /home/eichin/tmp/svnrmbug > $ svnadmin create repo > $ U=file://$(pwd)/repo > $ svn mk

The --password and clumsy users issue

This discussion kicked off on the wrong list, so since I started it, I've concatenated the posts. Intro: -- I used the --password option in a commit and then found that the process with my password in full view hung around for an entire week and could be seen by anyone with access to the same

Re: The --password and clumsy users issue

Ben wrote: > Rewriting the array isn't seen by the kernel. At least when I initially wrote > that example I tried just setting argv[++i] = "" and the ps output > didn't change. Could that be because of the libtool svn-lt script that sits in the middle? Because in gdb it does change, but not in p

Re: The --password and clumsy users issue

On 7/3/14 4:23 PM, Gabriela Gibson wrote: > Could that be because of the libtool svn-lt script that sits in the middle? > Because in gdb it does change, but not in ps. No because I wasn't even doing anything with Subversion yet let alone libtool. It was just a very basic C program with nothing mo

Re: The --password and clumsy users issue

Oh, I was playing about with this earlier, but didn't get all that far: I go this far in svn.c (has breakpoint marker in it) [[[ int main(int argc, char **argv) { apr_pool_t *pool; int exit_code = EXIT_SUCCESS; svn_error_t *err; const char **argv_org; /* Initiali

Re: The --password and clumsy users issue

I also looked at the C90 standard because I thought maybe they defined argv as immutable (since it should not complain about being const with this type of main declaration I think) and this is what is says: "The parameters argc and argv and the strings pointed to by the argv array shall be modifia

Re: The --password and clumsy users issue

On 7/3/14 4:50 PM, Gabriela Gibson wrote:> it compiles and runs and in gdb the vars do change, but the compiler isn't happy: > subversion/svn/svn.c: In function 'main': > > subversion/svn/svn.c:3048:23: warning: assignment discards 'const' qualifier > from pointer target type [enable\ > d by defaul

Re: The --password and clumsy users issue

On 07/04/14 04:47, Gabriela Gibson wrote: This is a summary of Ben's reply: Ben Reser wrote on Thu, Jul 03, 2014 at 12:54:58 -0700: > 1) Remove the option. > 2) Redact the password in the argv after starting up and finding the > bits to redact. 3) Allow the password to be supplied over std

Re: The --password and clumsy users issue

On 7/3/14 9:10 PM, Martin Furter wrote: > 3) Allow the password to be supplied over stdin using the special value "-". > > Nobody will see the password. The only leak is that a password has been > supplied using stdin. An attacker will have to convince the calling > application > to run something