Picon

[l10n] Translation status report for trunk r1621910

Translation status report for trunk <at> r1621910

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2744      80     254     478  ++++++++++++++++++++++++++U~~~oooo
    es    2247     577     807     526  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2555     269     494     108  +++++++++++++++++++++++UU~~~~~
    it    2111     713     936     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2238     586     858     763  ++++++++++++++++++UUUUU~~~~~~~oooooo
    ko    2383     441     628     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2298     526     759     499  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2323     501     726     296  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2087     737     949     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2713     111     284      72  ++++++++++++++++++++++++++U~~~
 zh_CN    2604     220     409      13  ++++++++++++++++++++++++UU~~~~
 zh_TW    2028     796     987     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Branko Čibej | 29 Aug 19:31 2014

Duplicating the NODES table

(this is mostly for Ben's benefit)

I ran a quick test to determine how expensive it would be to duplicate the whole nodes table as a basis for creating local workspaces. I used a wc.db from a checkout of the whole Subversion tree -- it's a couple months old, but quite representative, IMO, of the WC size that we're likely to encounter in the wild. The results are not encouraging and it'll be fun trying to speed this up by a factor of 10. This is all on SSD with hot caches, by the way.

(Note that I already added the required record in the WCROOT table.)


-- Brane

$ time sqlite3 all-subversion.copy.db 'select wc_id, count(*) from nodes group by wc_id;' 1|456410 real 0m0.072s user 0m0.060s sys 0m0.010s $ time sqlite3 all-subversion.copy.db 'insert into nodes select 2, local_relpath, op_depth, parent_relpath, repos_id, repos_path, revision, presence, moved_here, moved_to, kind, properties, depth, checksum, symlink_target, changed_revision, changed_date, changed_author, translated_size, last_mod_time, dav_cache, file_external, inherited_props from nodes where wc_id=1;' real 0m16.183s user 0m8.419s sys 0m5.338s $ time sqlite3 all-subversion.copy.db 'select wc_id, count(*) from nodes group by wc_id;' 1|456410 2|456410 real 0m0.126s user 0m0.107s sys 0m0.017s $ time sqlite3 all-subversion.copy.db 'delete from nodes where wc_id=2;' real 0m7.675s user 0m4.798s sys 0m2.489s


--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane <at> wandisco.com
DARKGuy . | 29 Aug 15:04 2014
Picon

C# SVN Encrypted Authentication wrapper for Windows and svnserve.exe

Hey all :)

I'm really proud to announce a small app I wrote located here ->
https://github.com/darkguy2008/SVNEncryptedAuth <- that will hook into
the svnserve.exe process and encrypt the passwords located in the
"passwd" file, while making it use a temporary file with the plaintext
passwords on access (deleted almost immediately for security).

This is made so the passwords don't get stored in plaintext but with
some sort of encryption. I don't know why this wasn't planned in the
release of that app, since we all know plaintext passwords are BAD and
SASL is a pain to set up under Windows (also, not portable since it
requires registry keys) and since I don't want to go with the hassle
of downloading the source code and compiling the whole thing,
developing an IAT hook patch was easier to do.

I hope you guys like the project and becomes useful for anyone here.

Comments & suggestions welcome, thanks!
- DARKGuy

Peter Galcik | 29 Aug 12:27 2014
Picon

Segmentation fault during diff generation

Hi devs,

I am using SVN on Solaris platform
( svn, version 1.8.5 (r1542147) compiled Feb 14 2014, 12:54:21 on i386-pc-solaris2.10)
 and Windows
 (svn, version 1.8.10 (r1615264) compiled Aug 12 2014, 04:08:18 on x86_64/x86-microsoft-windows5.1.2600)
 with changelist feature.

Normal svn diff command without changelist go well but when valid changelist is passed to command, crash occurs.

I am attaching crash log from windows (its collabnet subversion). I had to alter some information form command, hope its ok :)
If is needed more information, let me know.

Can you please check it. 

BR,
Peter
Attachment (svn-crash-log20140829115813.log): application/octet-stream, 12 KiB
Branko Čibej | 28 Aug 11:29 2014

A gentle reminder about procedure

Quoting from IRC (timezone GMT+2):
zhakov: stefan2: why you didn't wait for my reply regarding svnfsfs tool and commited stuff to trunk? Please revert it now! [5:57pm] Bert left the chat room. (Ping timeout: 240 seconds) [5:58pm] zhakov: stefan2: I mean r1620909. [5:59pm] stefan2: What is your concrete technical objection to r1620909? [5:59pm] zhakov: First of all: discussion about this approach is still going on dev <at> list. [5:59pm] zhakov: You suggested it and then didn't wait for my reply [6:00pm] zhakov: I'm waiting for revision to be reverted now [6:00pm] stefan2: That does not prevent (maybe temporary) solutions to be committed. [6:00pm] zhakov: no, no and no [6:01pm] zhakov: You're almost DDoS reviewers with your commits [6:02pm] stefan2: You request changes. You get changes.

Ivan, you're totally in the wrong in this case. Commit then review, remember?

The decision to move svnfsfs to the main install was made at the hackathon in Sheffield by a consensus of 8 developers and communicated to dev <at> . You raised the issue about private functions, which Stefan solved satisfactorily (in the explicit opinion of one other developer). Therefore, he went ahead and made the (completely reasonable) change.

You have exactly zero grounds to demand from other devs that they wait for your approval before committing anything. You are completely wrong in accusing Stefan that he ignores other developers' opinions; he did not even ignore your opinion. What he did was not wait for your approval of his solution, and that's entirely reasonable since he did get positive feedback from others.

And worst of all, you had the gall to complain to me, privately, about this; despite the fact that I told you plainly that discussions belong on the dev <at> list, and despite the fact that I also told you plainly that I'm not going to put any private pressure on anyone regarding their code. If you think that I, as Stefan's nominal boss, would even consider doing something like that, you'd better inform yourself a bit more on how we operate at the ASF, and specifically on this project.

If you have technical objections, by all means, raise them. If you find bugs, absolutely do report (or fix) them. But do not for a minute assume that you have any more say on this project than anyone else.

-- Brane


--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane <at> wandisco.com
Stefan Sperling | 27 Aug 11:38 2014
Picon

configurable svn+ssh remote tunnel commands

Apparently people are having trouble in some configurations with
the hardcoded 'svnserve -t' default remote tunnel command.

One problematic case seems to involve running a GUI Subversion
client on a Mac against a server on localhost via svn+ssh.
See #svn chat log at:
http://colabti.org/irclogger/irclogger_log/svn?date=2014-08-26#l248

As far as I understand the situation, apple is shipping an old svnserve
in /usr/bin and the user would prefer running a more recent
/usr/local/bin/svnserve.
Additionally, overriding per-user environment variables like PATH
seems to be a very difficult thing to do. I can't judge if this is
really the case since I don't use MacOS at all.

The user is requesting a config knob to override the default, to be
able to specify a full path to svnserve and add other flags to
svnserve's invocation as desired. This is indeed a fairly trivial
change. Do we want to add this?

Note that, with ssh keys, the server can override the tunnel command
requested by the client, which is another possible workaround.

This is diff is untested, just a proof of concept.

Index: subversion/include/svn_config.h
===================================================================
--- subversion/include/svn_config.h	(revision 1618039)
+++ subversion/include/svn_config.h	(working copy)
 <at>  <at>  -152,6 +152,8  <at>  <at>  typedef struct svn_config_t svn_config_t;
 #define SVN_CONFIG_OPTION_SQLITE_EXCLUSIVE_CLIENTS  "exclusive-locking-clients"
 /**  <at> since New in 1.9. */
 #define SVN_CONFIG_OPTION_SQLITE_BUSY_TIMEOUT       "busy-timeout"
+/**  <at> since New in 1.9. */
+#define SVN_CONFIG_SECTION_TUNNELS_REMOTE           "tunnels-remote"
 /**  <at> } */

 /**  <at> name Repository conf directory configuration files strings
Index: subversion/libsvn_ra_svn/client.c
===================================================================
--- subversion/libsvn_ra_svn/client.c	(revision 1618039)
+++ subversion/libsvn_ra_svn/client.c	(working copy)
 <at>  <at>  -436,8 +436,32  <at>  <at>  static svn_error_t *find_tunnel_agent(const char *
   *argv = apr_palloc(pool, (n + 4) * sizeof(char *));
   memcpy(*argv, cmd_argv, n * sizeof(char *));
   (*argv)[n++] = svn_path_uri_decode(hostinfo, pool);
-  (*argv)[n++] = "svnserve";
-  (*argv)[n++] = "-t";
+
+  /* Look up the tunnel remote command specification in config. */
+  cfg = config ? svn_hash_gets(config, SVN_CONFIG_CATEGORY_CONFIG) : NULL;
+  svn_config_get(cfg, &val, SVN_CONFIG_SECTION_TUNNELS_REMOTE, tunnel, NULL);
+  if (val)
+    {
+      char **remote_cmd_argv;
+
+      /* Tokenize the command into a list of arguments. */
+      status = apr_tokenize_to_argv(val, &remote_cmd_argv, pool);
+      if (status != APR_SUCCESS)
+        return svn_error_wrap_apr(status, _("Can't tokenize command '%s'"),
+                                  val);
+      while (*remote_cmd_argv != NULL)
+        {
+          (*argv)[n++] = *remote_cmd_argv;
+          remote_cmd_argv++;
+        }
+    }
+  else
+    {
+      /* Default tunnel remote command. */
+      (*argv)[n++] = "svnserve";
+      (*argv)[n++] = "-t";
+    }
+
   (*argv)[n] = NULL;

   return SVN_NO_ERROR;
Index: subversion/libsvn_subr/config_file.c
===================================================================
--- subversion/libsvn_subr/config_file.c	(revision 1618039)
+++ subversion/libsvn_subr/config_file.c	(working copy)
 <at>  <at>  -1249,6 +1249,13  <at>  <at>  svn_config_ensure(const char *config_dir, apr_pool
         "### path separator.  A single backslash will be treated as an"      NL
         "### escape for the following character."                            NL
         ""                                                                   NL
+        "### Section for configuring remote tunnel commands."                NL
+        "[tunnels-remote]"                                                   NL
+        "### Configure the command to be executed at the remote end"         NL
+        "### of a given tunnel configured in the [tunnels] section."         NL
+        "### The default remote tunnel command is 'svnserve -t'."            NL
+        "ssh = /opt/svn/bin/svnserve -t"                                     NL
+        ""                                                                   NL
         "### Section for configuring miscellaneous Subversion options."      NL
         "[miscellany]"                                                       NL
         "### Set global-ignores to a set of whitespace-delimited globs"      NL

Ivan Zhakov | 26 Aug 17:19 2014

Implement major FSFS performance related changes in the experimental FSX format

I propose to design and implement all major performance related
changes of the current FSFS format in the experimental FSX format.
I mean features exactly like revprop caching and log addressing.

The best possible option for such features is to be implemented and
released as a part of experimental FSX. Then, when we will be really
sure that everything is fine and it works for the wide number of users,
we can selectively port (not merge) some of the features into the FSFS.

We have successfully followed this approach in the past (FSFS itself
and ra_serf) and currently I do not see any reasons to change this
approach for features I'm talking about. Moreover, we have discussed
this on Berlin 2013 hackathon [1]:
[[[
stefan2 expressed that while he is confident that FSFSv7 is solid code,
it's also quite critical and could easily take a year or more to fully
stabilize. Attendees felt that perhaps it would be best to introduce FSFSv7
as a new, experimental fs-type. Stefan said he had been thinking
about the same thing himself, even considering a different name for
his implementation.
]]]

At this point I'm '-1' to:
1) release the improved version of revprop caching to the FSFS format [2]

2) release the log addressing feature in the FSFSv7 format

The current implementation of revprop caching and log-addressing features
should be reverted from trunk and moved to FSX.

[1] http://wiki.apache.org/subversion/Berlin2013#FSFSv7_Branch_Reintegration
[2] http://svn.apache.org/repos/asf/subversion/branches/revprop-caching-ng

--

-- 
Ivan Zhakov

Stefan Fuhrmann | 26 Aug 17:04 2014

Revprop-caching-ng branch ready for review

Hi all,

Please review the changes in that branch such that
it can be merged to /trunk.

Basically, we replace the shared memory code with
plain file access and keep the revprop caching and
invalidation logic unchanged. Also, we make sure that
writes don't rely on existing buffer / cache contents,
i.e. there are no lost updates. See BRANCH-README
for more details.

The main logic can be found in revprops.c, lines 149-622;
it's probably easiest to read the new code as-is instead
of looking at the diff for that section.

Here the guarantees and limitations of the new implementation:

* No lost updates in revprop file contents even if the
  SVN caches should be stale.
* A connection (svn_fs_t) will always see at least all
  changes up to and including its own last revprop change.
* A new connection will always see all changes made
  up to the point the connection got created.

* On Windows and Unixoids, readers will always see
  the latest data if they are on the same machine as the
  writing process.
* Depending on OS read cache configuration and if the
  repository is shared between machines, open connections
  *might* no see revprop updates or might see them delayed
  (the open revprop generation file handle may see a stale
  OS file buffer).
* Revprop caching may be inefficient if the repository is
  shared between machines; again depending on OS config.

-- Stefan^2.
Alexey Neyman | 26 Aug 06:32 2014
Picon
Picon

Python bindings for repos.parse_dumpstream{2,3}?

Hi,

 

Am I correct that repos.parse_dumpstream{2,3} are currently unusable from Python bindings? These functions take a vtable as one of the arguments, but the generated bindings for svn_repos_parse_fns{2,3}_t implement *calling* of the vtable methods rather than a way of overriding them.

 

If I understand correctly, for these functions to be usable, the bindings need to implement a wrapper similar to delta.Editor class. Am I right?

 

Regards,

Alexey.

Picon

[l10n] Translation status report for trunk r1620506

Translation status report for trunk <at> r1620506

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2746      78     256     478  ++++++++++++++++++++++++++U~~~oooo
    es    2249     575     809     526  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2557     267     496     108  +++++++++++++++++++++++UU~~~~~
    it    2113     711     938     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2240     584     860     763  ++++++++++++++++++UUUU~~~~~~~~oooooo
    ko    2385     439     630     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2300     524     761     499  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2325     499     728     296  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2089     735     951     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2715     109     286      72  ++++++++++++++++++++++++++U~~~
 zh_CN    2606     218     411      13  ++++++++++++++++++++++++UU~~~~
 zh_TW    2030     794     989     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Alexey Neyman | 23 Aug 20:51 2014
Picon
Picon

Alternative for svn_load_dirs.pl?

Hi all,

 

Attached is a alternative for the svn_load_dirs.pl. Unlike svn_load_dirs.pl, this svn-import.py can automatically detect the renames, including renames of the whole directories.

 

The usage is described in the large comment at the top of the script.

 

Worth adding to contrib?

 

Regards,

Alexey.

 

 

 

 

Attachment (svn-import.py): text/x-python, 38 KiB

Gmane