Julian Foad | 22 Jul 13:40 2014

Mergeinfo is not per node

For those interested in merging etc., a note on a recent line of thought.

For some time now I've had this idea going round my head that mergeinfo theoretically belongs to each node
separately, and that we "elide" subtree mergeinfo only for convenience, compactness, and to make it less
obtrusive and more easily understandable to the user.

It seemed a nice idea, but it's wrong. Mergeinfo is not inherently "per node".

WHY?

The content of two branches is usually *different* -- that's the point of branches.

In the per-file model of branching used by CVS, for example, each file is branched, and the content of each
branch of that file can differ. This means for each file in the source tree there is one obviously
corresponding file in the target tree.

In Subversion the intention is to version trees rather than just separate files, and so two branches can
differ in tree structure as well as in file content. The changes to one file on branch B1 can correspond to
changes in two files on branch B2, or in no particular file on branch B2, and so on. A merge cannot assume
there is a 1-to-1 mapping of nodes.

Imagine the change on branch B1 at revision 100 consists of renaming a function, and updating all calls to
it. The change affects files foo.c and foo.h and bar.c. When we merge this change to the target branch B2, we
have to adjust the result, manually and/or automatically,  to fit the target branch. Perhaps foo and bar
have been combined into a single file foobar.c on branch B2, and so the change affects only foobar.c. This
does not mean foobar.c alone has received that change, as that would imply all other nodes are still
eligible to receive that change. Rather, the information we need to track is that the target branch as a
whole has received the change as a whole.

- The merge source changes may be a selection of changes from just one subtree (or more generally a subset of
(Continue reading)

Picon

[l10n] Translation status report for trunk r1612454

Translation status report for trunk <at> r1612454

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2723      59     228     471  +++++++++++++++++++++++++++~~~oooo
    es    2230     552     791     528  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2534     248     472     109  +++++++++++++++++++++++UU~~~~~o
    it    2096     686     922     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2223     559     844     763  ++++++++++++++++++UUUUU~~~~~~~oooooo
    ko    2365     417     611     219  ++++++++++++++++++++UUUU~~~~~~o
    nb    2280     502     742     501  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2305     477     709     298  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2072     710     936     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2694      88     259      67  ++++++++++++++++++++++++++U~~~
 zh_CN    2583     199     384       7  ++++++++++++++++++++++++UU~~~~
 zh_TW    2013     769     974     377  ++++++++++++++++UUUUUU~~~~~~~~ooo

Jacky wong | 21 Jul 14:44 2014
Picon

(unknown)

Julian Foad | 17 Jul 17:38 2014

Three little diff bugs

I just noticed some 'svn diff' bugs, using svn trunk <at> 1611327 (with a few local mods related to mergeinfo
parsing, that should not affect diffs).

Bug 1.

We print a diff header in front of an empty diff, for a copied-but-not-modified file, where we didn't previously.

[[[
$ svn cp ^/trunk/alpha <at> 1 alpha2
A         alpha2
$ svn diff
Index: alpha2
===================================================================
$ svn18 diff   # svn18 is Subversion 1.8.9
]]]

Bug 2.

We show the left-hand-side revision as 'nonexistent' for a copied-and-modified file diff, where the real
left-hand side of the diff is the copy-from revision (revision 1 in this example).

[[[
$ echo foo >> alpha2 
$ svn diff  # diffing against the copy source
Index: alpha2
===================================================================
--- alpha2    (nonexistent)
+++ alpha2    (working copy)
 <at>  <at>  -1 +1,2  <at>  <at> 
 alpha
+foo
$ svn info alpha2
[...]
Relative URL: ^/trunk/alpha2
Revision: 1
Schedule: add
Copied From URL: file:///.../trunk/alpha
Copied From Rev: 1
Last Changed Rev: 1
]]]

Bug 3.

A WC-WC diff shows a replace-with-copy-from-self as a delete and an add, when the 'notice-ancestry'
option is given. (If we commit the change, then a repos-repos diff of the change with '--notice-ancestry'
shows a single diff, as it should.)

I suppose the WC-WC diff always assumes that any copied replacement node is unrelated to the replaced node.

In the (very) special case where the copy source path and revision are exactly equal to the replaced node's
base path and revision, this would be easy to detect as related, but other cases would, in general, require
contacting the repository.

[[[
$ svn rm alpha 
D         alpha
$ svn cp ^/trunk/new/alpha <at> 3 alpha
A         alpha
$ echo bar >> alpha 

$ svn diff --notice-ancestry 
Index: alpha
===================================================================
--- alpha    (revision 6)
+++ alpha    (nonexistent)
 <at>  <at>  -1,2 +0,0  <at>  <at> 
-alpha
-hello
Index: alpha
===================================================================
--- alpha    (nonexistent)
+++ alpha    (working copy)
 <at>  <at>  -1 +1,2  <at>  <at> 
 alpha
+bar
]]]

- Julian

Matthias Gerstner | 17 Jul 13:22 2014

[PATCH] optionally disable normalization of working copy files in diff invocations

Hello,

attached is a patch against the current subversion trunk state (revision
1611327) that fixes a problem when using external diff programs that's
also been described years ago here:

http://svn.haxx.se/users/archive-2008-10/0664.shtml

----
When passing the new diff command line option --no-normalization then
svn diff won't create and pass on a temporary, normalized version of a
file for local working copy files.

This normalization is the default behaviour when svn diff encounters
files that have the svn:keywords or svn:eol-style properties set, such
that the base version and the working copy version of the file have the
same format.

This makes it impossible to edit diffed files when using an external
--diff-cmd that supports editing, because the file passed to the
external tool is a temporary file that will be deleted afterwards,
instead of the original working copy file.

When passing --no-normalization the original file is passed to the diff
tool instead. External tools that can ignore whitespace differences
(present due to svn:eol-style) can still display decent diffs and the
benefit of editing the diffed files in place is helpful.
----

Best regards,

Matthias Gerstner

--

-- 
Matthias Gerstner, Dipl.-Wirtsch.-Inf. (FH)
Entwicklung

NCP engineering GmbH
Dombühler Straße 2, D-90449, Nürnberg
Geschäftsführer Peter Söll, HRB-Nr: 77 86 Nürnberg

Telefon: +49 911 9968-153, Fax: +49 911 9968-229
E-Mail: Matthias.Gerstner <at> ncp-e.com
Internet: http://www.ncp-e.com
Attachment (normalize.patch): text/x-diff, 16 KiB
Picon

[l10n] Translation status report for trunk r1610571

Translation status report for trunk <at> r1610571

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2722      59     226     471  +++++++++++++++++++++++++++~~~oooo
    es    2230     551     791     528  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2533     248     470     109  +++++++++++++++++++++++UU~~~~~o
    it    2095     686     921     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2222     559     843     763  ++++++++++++++++++UUUUU~~~~~~~oooooo
    ko    2364     417     610     219  ++++++++++++++++++++UUUU~~~~~~o
    nb    2279     502     741     501  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2304     477     708     298  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2071     710     935     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2693      88     257      67  ++++++++++++++++++++++++++U~~~
 zh_CN    2582     199     383       7  ++++++++++++++++++++++++UU~~~~
 zh_TW    2013     768     974     377  ++++++++++++++++UUUUUU~~~~~~~~ooo

Stefan Fuhrmann | 14 Jul 01:54 2014

Performance Results on Windows

After almost a week of continuous measurements and 4320
individual data point, the results are in now. Summary:

* on cold disks, 'svn log -v' is 2x..3x as fast with packed f7 than with
  packed f6 in default config and up to 8x with advanced options
* on cold disks, 'svn export' with packed f7 is 40%.50% faster in
  default config and 2x as fast with advanced options
* ra_serf has an anomaly making "fast" config up to 100x slower
  than ra_svn - independent of repo format

Details to how I set up the repositories and measurements plus
the rationale behind it can be found in our wiki:

https://wiki.apache.org/subversion/MeasuringRepositoryPerformance

Tools and test script have been committed in r1610264. System
setup is close to what Ivan used in his tests, except for having
4GB to accommodate the much larger BSD repo as well.

Original measurement log and detailed results can be found in the
.zip file attached. The spreadsheet has been upgraded and now
displays f6/f7 because "+400%" is easier to understand than "-80%".
It now also highlights data cells with particularly high variation.

I'm currently waiting for the 'svnadmin dump' results to come in.
Those will take about 3 days but the expectation is that packed f7
may be slightly slower here due to the "unusual" access pattern.
After that, I'll try to isolate the trigger for the ra_serf anomaly.

-- Stefan^2.
Attachment (fsfsPerfWin.pdf): application/pdf, 159 KiB
Attachment (WinPerf.zip): application/zip, 655 KiB
Jacky wong | 9 Jul 19:49 2014
Picon

(unknown)

Support

Branko Čibej | 8 Jul 11:54 2014

The svn-x64-macosx-gnu-shared* builders

It appears that the svn-x64-macosx-gnu-shared* buildbot scripts are not used.

Does anyone object to my removing/renaming/recycling them to set up a builder or two on the Mac Mini that's sitting around for that very purpose?

-- Brane


--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane <at> wandisco.com
Picon

[l10n] Translation status report for trunk r1608656

Translation status report for trunk <at> r1608656

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2722      59     226     471  +++++++++++++++++++++++++++~~~oooo
    es    2230     551     791     528  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2533     248     470     109  +++++++++++++++++++++++UU~~~~~o
    it    2095     686     921     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2222     559     843     763  ++++++++++++++++++UUUUU~~~~~~~oooooo
    ko    2364     417     610     219  ++++++++++++++++++++UUUU~~~~~~o
    nb    2279     502     741     501  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2304     477     708     298  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2071     710     935     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2693      88     257      67  ++++++++++++++++++++++++++U~~~
 zh_CN    2582     199     383       7  ++++++++++++++++++++++++UU~~~~
 zh_TW    2013     768     974     377  ++++++++++++++++UUUUUU~~~~~~~~ooo

Martin Furter | 8 Jul 04:38 2014
Picon

Re: [PATCH]: Add --password-file and --password-envvar

Again reply to the list too :)

GUI's which change buttons etc. depending on whatever they like are bad...

On 07/08/14 08:02, Martin Furter wrote:
> On 07/08/14 03:33, Ben Reser wrote:
>> On 7/6/14 5:16 AM, Martin Furter wrote:
>>> Attached is a log message and a patch which adds the new options
>>> '--password-file' and '--password-envvar'. It also adds Julians
>>> warning to the
>>> '--password' help text.
>>
>> I veto (-1) --password-envar (and peters follow-up suggestion of a
>> hard-coded
>> environment variable). As several other people have shown the
>> environment of a
>> running program is often just as available as the command line
>> arguments. The
>> whole point of this exercise is to improve the security of the manner
>> in which
>> we allow passwords to be provided in order to guide users to make good
>> choices.
>> We're not achieving anything if we only provide them with new insecure
>> choices.
>
> On Linux I see only the environment of my own processes. On OpenBSD I
> see only HOME and PATH for other users. So envvar seems to not be less
> secure than a password file.
>
> If you really want to improve security the only option is using stdin.
>
> I had a patch for that ready. But then people started wishing other
> things so I just implemented without thinking too much :)
>
> - Martin

Allow the password to be supplied through stdin.

* subversion/svn/svn.c
  (sub_main): Read the password from stdin when '-' is specified. Disallow
    multiple use of '-' for the options --password and -F.

Index: subversion/svn/svn.c
===================================================================
--- subversion/svn/svn.c	(revision 1607783)
+++ subversion/svn/svn.c	(working copy)
 <at>  <at>  -2018,9 +2018,16  <at>  <at> 
          * later (if it's a log/lock message or an svn:* prop value),
          * according to the value of the '--encoding' option. */
         SVN_ERR(svn_utf_cstring_to_utf8(&utf8_opt_arg, opt_arg, pool));
+        if (strcmp(utf8_opt_arg, "-") == 0)
+          {
+            if (reading_file_from_stdin)
+              return svn_error_create(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
+                                      _("stdin ('-') must not be specified "
+                                        "more than once"));
+            reading_file_from_stdin = TRUE;
+          }
         SVN_ERR(svn_stringbuf_from_file2(&(opt_state.filedata),
                                          utf8_opt_arg, pool));
-        reading_file_from_stdin = (strcmp(utf8_opt_arg, "-") == 0);
         dash_F_arg = utf8_opt_arg;
         break;
       case opt_targets:
 <at>  <at>  -2094,8 +2101,24  <at>  <at> 
                                         opt_arg, pool));
         break;
       case opt_auth_password:
-        SVN_ERR(svn_utf_cstring_to_utf8(&opt_state.auth_password,
-                                        opt_arg, pool));
+        SVN_ERR(svn_utf_cstring_to_utf8(&utf8_opt_arg, opt_arg, pool));
+        if (strcmp(utf8_opt_arg, "-") == 0)
+          {
+            svn_stringbuf_t *buffer, *buffer_utf8;
+
+            if (reading_file_from_stdin)
+              return svn_error_create(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
+                                      _("stdin ('-') must not be specified "
+                                        "more than once"));
+            reading_file_from_stdin = TRUE;
+            SVN_ERR(svn_stringbuf_from_file2(&buffer, utf8_opt_arg, pool));
+            SVN_ERR(svn_utf_stringbuf_to_utf8(&buffer_utf8, buffer, pool));
+            opt_state.auth_password = buffer_utf8->data;
+          }
+        else
+          {
+            opt_state.auth_password = utf8_opt_arg;
+          }
         break;
       case opt_encoding:
         opt_state.encoding = apr_pstrdup(pool, opt_arg);

Gmane