Picon

[l10n] Translation status report for trunk r1625212

Translation status report for trunk <at> r1625212

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2753      94     264     478  ++++++++++++++++++++++++++U~~~oooo
    es    2254     593     814     526  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2564     283     503     108  ++++++++++++++++++++++UUU~~~~~
    it    2118     729     943     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2245     602     865     763  ++++++++++++++++++UUUUU~~~~~~~oooooo
    ko    2390     457     635     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2305     542     766     499  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2330     517     733     296  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2094     753     956     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2722     125     293      72  ++++++++++++++++++++++++++U~~~
 zh_CN    2616     231     421      13  ++++++++++++++++++++++++UU~~~~
 zh_TW    2035     812     994     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Stefan Sperling | 10 Sep 19:06 2014
Picon

[VOTE] merge the log-message-templates branch to trunk

I've been working on the log-message-templates branch recently.
This branch was started by cmpilato a long time ago but for some
reason sat around untouched ever since. It's now been overhauled
by me with much help from Bert.

I believe the functionality is useful and complete. One user I have
in mind who would probably make use of this is the FreeBSD project.
They patch their Subversion clients to define a log message template
with the following content:
[[[
PR:
Submitted by:
Reviewed by:
Approved by:
Obtained from:
MFC after:
MFH:
Relnotes:
Security:
Sponsored by:
]]]
The patch is here:
http://svnweb.freebsd.org/ports/head/devel/subversion/files/extra-patch-fbsd-template?revision=361003&view=markup
With the changes on the log-message-templates branch, they can drop their
custom patch and add their log message template to an svn:log-template
property instead.

I believe many other users might find this feature useful as well.

The current diff between the trunk and branch is this:
(Continue reading)

Ivan Zhakov | 10 Sep 17:35 2014

named_atomic tests failures on Windows

I've accidentally ran Subversion test suite under elevated local
administrator account on Windows and got failures in named-atomics
tests:
[[[
..\..\..\subversion\tests\libsvn_subr\named_atomic-test.c:520:
(apr_err=SVN_ERR_TEST_FAILED)
svn_tests: E200006: assertion 'value == 42' failed at
..\..\..\subversion\tests\libsvn_subr\named_atomic-test.c:520
FAIL:  named_atomic-test.exe 1: basic r/w access to a single atomic
..\..\..\subversion\tests\libsvn_subr\named_atomic-test.c:581:
(apr_err=SVN_ERR_TEST_FAILED)
svn_tests: E200006: assertion 'value == 42 * HUGE_VALUE' failed at
..\..\..\subversion\tests\libsvn_subr\named_atomic-test.c:581
FAIL:  named_atomic-test.exe 2: atomics must be 64 bits
..\..\..\subversion\tests\libsvn_subr\named_atomic-test.c:643:
(apr_err=SVN_ERR_TEST_FAILED)
svn_tests: E200006: assertion 'value1 == 46 * HUGE_VALUE' failed at
..\..\..\subversion\tests\libsvn_subr\named_atomic-test.c:643
FAIL:  named_atomic-test.exe 3: basic r/w access to multiple atomics
]]]

The investigation revealed the following:
1. The named_atomics tests are skipped unless executed under elevated
    local administrator on Windows.
2. The named_atomics are never properly worked on Windows.

A little bit more detailed explanation:
Originally "named atomics" framework was using shared memory for syncronization.
Creating shared memory on Windows requires administrative permissions, so
svn_named_atomic__is_supported() had check if application has necessary
(Continue reading)

Alexey Neyman | 9 Sep 07:56 2014
Picon
Picon

fs-fs-fuzzy-test fails to build due to missing dependency

Hi all,

 

fs-fs-fuzzy-test fails to build for me (Ubuntu 14.04 + current updates) with a "DSO missing from the command line" error. Anyone objecting to the attached patch?

 

[[[

* build.conf

(fs-fs-fuzzy-test) Add libsvn_repos as a dependency.

]]]

 

Regards,

Alexey.

Attachment (fsfs-fuzzy-test.diff): text/x-patch, 462 bytes
Picon

[l10n] Translation status report for trunk r1623618

Translation status report for trunk <at> r1623618

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2753      94     263     478  ++++++++++++++++++++++++++U~~~oooo
    es    2254     593     814     526  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2564     283     503     108  ++++++++++++++++++++++UUU~~~~~
    it    2118     729     943     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2245     602     865     763  ++++++++++++++++++UUUUU~~~~~~~oooooo
    ko    2390     457     635     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2305     542     766     499  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2330     517     733     296  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2094     753     956     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2722     125     293      72  ++++++++++++++++++++++++++U~~~
 zh_CN    2616     231     421      13  ++++++++++++++++++++++++UU~~~~
 zh_TW    2035     812     994     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Ivan Zhakov | 8 Sep 18:24 2014

Re: Implement major FSFS performance related changes in the experimental FSX format

> (FWIW, maintaining the remove-log-addressing branch doesn't count, and
> frankly I have a hard time imagining how that branch could be less buggy
> than trunk, given that it's received far less attention and testing.)
As you should know, current FSFS code on trunk is like this:
if (log_addressing_enabled(rev))
{
    do_one();
}
else
{
    do_else();
}

And this covers *all* cases, because FSFS code supports reading and
*writing* all previous FSFS formats. I've just removed do_one() calls on
remove-log-addressing branch. How this could be more buggy?? Please
provide more details about this point.

> You must have forgotten the history of ra_serf: almost nobody used it
> until we made it the default and only option, and so we only started
> getting useful feedback after the 1.8.0 release.

We release features not just to get a 'useful feedback' from the users.
There was a lot of work to prepare ra_serf to be the default option. I guess
we would have a different kind of feedback if this work have not been done.

>> 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.
>> ]]]
> Yup, we did; more than a year ago. A lot has changed since then.
What exactly have changed and where it was discussed?

> I'll even go as far as to suspect that you're not aware there's no revprop
> caching on trunk right now.

Should I suspect that you are saying this to make it seem that I don't have
any technical ground behind my position?

As I said elsethread, I routinely read everyone's commits to Subversion
codebase (with different level of attention, of course). Moreover, both
problems that caused to disable revprop caching on trunk were initially
found by two of my colleagues. So, despite the fact that I've been on
vacation when r1619774 was committed, I obviously know the story.

Also, I do not see yours '+1' or other kind of positive feedback regarding
the revprop-caching-ng branch.

Have you got a chance to review the revprop-caching-ng branch?

Do you agree with all the significant technical solutions adopted in
this branch?

--

-- 
Ivan Zhakov

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

Gmane