Storm-Olsen, Marius | 24 Apr 05:42 2014
Picon

Open Source Organizational Culture

Hi,

I would like to request your participation in a survey on
     Open Source Organizational Culture,
which will provide valuable insight into how Open Source projects are 
run, how their participants act, how they might change going forward, 
and how particular Open Source projects compare with one another and 
with traditional business cultures. The survey shouldn't take more than 
10-15 minutes to complete.

Some of the projects already participating in the survey include Qt, 
KDE, OpenStack, Git, Bazaar, Perl, Python and Ruby on Rails.

     http://bit.ly/OSOCAS2014

Why?
----
The survey will be used as part of my thesis on Open Source 
Organizational Culture at BI Norwegian Business School (www.bi.no/en, or 
www.bi.edu), but in true Open Source spirit the raw - but anonymized - 
results will be open for all. So, your Open Source project will be able 
to massage and dissect the results any way you wish, and see how you 
compare with other projects out there.

Up until now, most research in Open Source culture has been based on 
mining mailing lists to find out how people act, who they interact with, 
and how projects organize themselves.

In this research we would rather ask the participants directly about how 
a project is managed and what should change for the project to be 
(Continue reading)

Michael Schierl | 22 Apr 17:51 2014
Picon
Picon

"E160016: Path 'parent/child' not present" when "svn cp"ing modified folder between two checkouts from same repository and trying to commit

[please cc: me as I'm not subscribed to this list.]

Hi,

It seems that copying some changed/added files between two working
copies of the same repository does not work, not even if both
repositories are at the latest revision.

Discussion in #svn on Freenode:

> <mihi> Is it expected to work when I have two checkouts of different branches of the same repo (both at the
latest revision) to "svn cp" one modified folder from one repo to the other (it did not exist in the other
branch before) and then commit from there (together with changes that are already there)? Because I'm
getting strange "path not present" error messages...
> <mihi> I've done it a lot but not sure whether it is really a bug, especially considering the scary message
on http://subversion.tigris.org/issue-tracker.html#find :)
> <mihi> and I can reproduce it: http://pastebin.com/x1yMdt0C
> <Bert> mihi: Copying between working copies of the same repository should work.. But when mixing things
with mixed revisionness, replacements, etc. there are a lot of corner cases.
> <Bert> There are some fixes that might fix this case nominated for the next 1.8.x release.
> <Bert> mihi: Can you post this testcase to dev{_AT_}subversion.apache.org?

To reproduce:

> X:\>svn --version
> svn, version 1.8.8 (r1568071)
>    compiled Apr 12 2014, 14:17:25 on x86-microsoft-windows
> 
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people;
(Continue reading)

Ivan Zhakov | 21 Apr 19:05 2014

Allocation of read buffers (was Re: svn commit: r1535686 - in /subversion/branches/log-addressing/subversion: include/svn_error_codes.h libsvn_fs_fs/transaction.c tests/libsvn_fs_fs/ tests/libsvn_fs_fs/fs-fs-pack-test.c)

On 21 April 2014 19:49, Stefan Fuhrmann <stefan.fuhrmann <at> wandisco.com> wrote:
> On Mon, Apr 21, 2014 at 9:37 AM, Ivan Zhakov <ivan <at> visualsvn.com> wrote:
>>
>> On 20 April 2014 22:38, Stefan Fuhrmann <stefan.fuhrmann <at> wandisco.com>
>> wrote:
>> >
>> > On Sat, Apr 19, 2014 at 10:32 PM, Ivan Zhakov <ivan <at> visualsvn.com>
>> > wrote:
>> >>
>> >> On 25 October 2013 15:12,  <stefan2 <at> apache.org> wrote:
>> >> > Author: stefan2
>> >> > Date: Fri Oct 25 11:12:27 2013
>> >> > New Revision: 1535686
>> >> >
[...]
>> >> > +/* Determine the checksum for the SIZE bytes of data starting at
>> >> > START
>> >> > + * in FILE and return the result in *FNV1_CHECKSUM.
>> >> > + * Use POOL for tempoary allocations.
>> >> > + */
>> >> > +static svn_error_t *
>> >> > +fnv1a_checksum_on_file_range(apr_uint32_t *fnv1_checksum,
>> >> > +                             apr_file_t *file,
>> >> > +                             apr_off_t start,
>> >> > +                             apr_off_t size,
>> >> > +                             apr_pool_t *pool)
>> >> > +{
>> >> > +  char buffer[4096];
>> >> > +
>> >> Why you're using non-standard sized buffer for IO operations on stack?
(Continue reading)

neels | 21 Apr 02:21 2014
Picon

[svnbench] Failed to build Revision: 1588844.

Failed to build Revision: 1588844.

Bert Huijben | 20 Apr 17:32 2014
Picon

[Review request] RE: svn commit: r1588772 - in /subversion/trunk/subversion: mod_dav_svn/repos.c tests/cmdline/commit_tests.py


> -----Original Message-----
> From: rhuijben <at> apache.org [mailto:rhuijben <at> apache.org]
> Sent: zondag 20 april 2014 16:47
> To: commits <at> subversion.apache.org
> Subject: svn commit: r1588772 - in /subversion/trunk/subversion:
> mod_dav_svn/repos.c tests/cmdline/commit_tests.py
> 
> Author: rhuijben
> Date: Sun Apr 20 14:46:42 2014
> New Revision: 1588772
> 
> URL: http://svn.apache.org/r1588772
> Log:
> Implement an initial fix for issue #4480. As noted in the code this patch
> might make this code report out of date in a few cases where we should
> allow
> a commit, but this is much safer than not reporting out of date where we
> should.
> 
> As far as I can tell this check matches how we do things in the repos/fs
> commit api, so I hope somebody with more knowledge of these apis can
> confirm that this is the right fix to close issue #4480.

	Hi all,

This issue has been bothering me for weeks, because I couldn't think of a proper way to fix this.

I think this patch (improved by r1588778) resolves the issue, but I would welcome reviews.

(Continue reading)

Post Master | 16 Apr 19:47 2014
Picon

using system groups in svnaccess.conf


subversion need to specify group members in the 'groups' 
section of
svnaccess.conf configuration file.
external access control system like LDAP, AD, &etc. 
requires to syncronize group
members to svnaccess.conf (for example: 
http://thoughtspark.org/node/26/).
subversion must query operating system for group members 
directly.
for example: on posix systems from nss (ldap, nis, 
/etc/group ...). on windows:
from AD or local groups.

authz_posixgroup_contains_user.patch is a prototype for 
posix system (getgrnam).

svnaccess.conf may be like that:

[repos1:/]
%wheel = rw
%members.test.bla-bla-bla = r

'%'-prefix means system group

http://subversion.tigris.org/issues/show_bug.cgi?id=4489
Daniel Shahaf | 17 Apr 13:12 2014

Tonight's svn-role merges - bug analysis

There were 9 merges tonight (r1588145:r1588153).  The log messages were
all correct, but the Nth merge removed from STATUS the (2N)th merge's
entry.  As a result, the first merge (N=0) was correct, but the others
either removed the wrong STATUS entry or removed no entry.

I think this is due to a bug in the relatively new $parno handling.  I
believe the parno code wasn't on the VM until yesterday, even though
it's been in HEAD for a while.

The code stows $parno in the %entry structure at parse time, and then
loops over the entries in Approved and merges them.  The first merge
deletes the ($entries[0]->{parno})th paragraph from STATUS.¹  The second
merge then deletes the ($entries[1]->{parno})th paragraph from the
file... which is wrong; it should be deleting the ($entries[1]->{parno} - 1)th
paragraph instead, since the first merge has happened, and
$entries[0]->{parno} < $entries[1]->{parno}.

The fix would be to change the $parno accounting as follows: before
$entry{parno} is used, subtract from it the number of entries already
merged in this run.  (Entries are currently merged in file order, so
none of the already-merged-in-this-run entries would have a ->{parno}
greater than $entry{parno} of the entry about to be merged.)

Daniel

P.S. It would be a good idea to have some sort of test suite for
backport.pl...

¹ There is no  <at> entries array; that was just pseudosyntax for "the first entry".

(Continue reading)

Ben Reser | 15 Apr 02:29 2014

Intent to roll 1.7.17/1.8.9

I intend to roll 1.7.17 and 1.8.9 sometime next week.  Please take some time
over the next week to look at STATUS in the respective branches and vote for
issues.

Thanks.

Ben Reser | 14 Apr 17:56 2014
Picon

Apache Subversion 1.9.0-alpha2 released

I'm happy to announce the release of Apache Subversion 1.9.0-alpha2.
Please choose the mirror closest to you by visiting:

    http://subversion.apache.org/download/#pre-releases

The SHA1 checksums are:

    c1de8633db4d8bc4b3145fec51b4079ca560f2a3 subversion-1.9.0-alpha2.tar.bz2
    bfbe16a6820d78bf124b779e5c8f641cd9fcc343 subversion-1.9.0-alpha2.zip
    2f563294e26d0ec806eef01f2e9e9231cafe3508 subversion-1.9.0-alpha2.tar.gz

PGP Signatures are available at:

    http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.tar.bz2.asc
    http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.tar.gz.asc
    http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.zip.asc

For this release, the following people have provided PGP signatures:

   Ben Reser [4096R/16A0DE01] with fingerprint:
    19BB CAEF 7B19 B280 A0E2  175E 62D4 8FAD 16A0 DE01
   Bert Huijben [4096R/CCC8E1DF] with fingerprint:
    3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Branko Čibej [4096R/A347943F] with fingerprint:
    BA3C 15B1 337C F0FB 222B  D41A 1BCA 6586 A347 943F
   Johan Corveleyn [4096R/010C8AAD] with fingerprint:
    8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
   Philip Martin [2048R/ED1A599C] with fingerprint:
    A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Stefan Fuhrmann [4096R/57921ACC] with fingerprint:
(Continue reading)

Stefan Fuhrmann | 14 Apr 16:05 2014

Fulltext caching and server (non-)scalability

Hi all,

This is nothing new (introduced way back when in 1.6),
but I have only become aware of it during my recent
scalability testing. I think I can fix that but that won't
happen until the end of next week or so.

Scenario: Large files have been cached and now a
number of clients request these files. The critical bit
here is N clients requesting say a 1GB file each.
ra_serf may request 2 of these. It may be the same
or different files.

What happens: N x 1GB is fetched from cache, each
held in some buffer and streamed out from there.

Problem: How many of those GB-sized buffers can
your server hold before going OOM?

Solution: Fetch only chunks of a configurable size
(default 16MB) from caches that support it and limit
other caches (memcached) to 1 chunk max. per file.
Fall back to standard reconstruction from deltas
when data gets evicted from cache while some chunks
have not been delivered, yet. This can be hidden
behind our existing stream interface.

-- Stefan^2.
neels | 14 Apr 02:21 2014
Picon

[svnbench] Failed to build Revision: 1587128.

Failed to build Revision: 1587128.


Gmane