1.7.3 up for signing / testing

At long last, here are the 1.7.3 tarballs for testing and signing:
http://people.apache.org/~hwright/svn/1.7.3/

The magic revision is r1242825.  Testing from committers and other
enthusiastic users is encouraged.  PMC members, please forward you
signatures to me in the usual method:
http://work.hyrumwright.org/pub/svn/collect_sigs.py

Reminder to downstream packagers: you are welcome to test this
release, as well as start your bundling process, but please don't
release anything based upon this release yet.  The Apache Subversion
community reserves the right to change, postpone or otherwise scuttle
this release with no warning, and we'd hate for you to be left holding
the bag.

-Hyrum

--

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Re: svn commit: r1242608 - /subversion/branches/1.7.x/STATUS

Old code allows malicious servers to abort() the process libsvn is
linked to, new code doesn't.

Greg Stein wrote on Thu, Feb 09, 2012 at 22:14:39 -0500:
> DoS? With the old code: the client died. With the new code: the client
> dies. No change that I'm aware of, other than a nicer error message.
> 
> It seems the justification would be, "nicer error message" rather than
> anything about DoS.
> 
> Cheers,
> -g
> On Feb 9, 2012 6:46 PM, <danielsh <at> apache.org> wrote:
> 
> > Author: danielsh
> > Date: Thu Feb  9 23:46:06 2012
> > New Revision: 1242608
> >
> > URL: http://svn.apache.org/viewvc?rev=1242608&view=rev
> > Log:
> > Nominate r1242607.
> >
> > Modified:
> >    subversion/branches/1.7.x/STATUS
> >
> > Modified: subversion/branches/1.7.x/STATUS
> > URL:
> > http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1242608&r1=1242607&r2=1242608&view=diff
> >
> > ==============================================================================

[RFC] Make Python 2.5 minimum version for dev tools (including test suite)

I find myself wanting to use the 'with' statement in the test suite,
which was introduced in Python 2.5  Python 2.5 was released 5.5 years
ago, and while I'm sure somebody on some archaic platform somewhere
doesn't have it installed, I think we can reasonably assume that
Python 2.5 is generally available.  For reference, we currently
require and SQLite that is only 2.5-years-old.

(And for the historically minded among us, let's please don't repeat
the same bikeshed we had when we bumped to Python 2.4 3 years ago:
http://svn.haxx.se/dev/archive-2009-01/0266.shtml)

I would like to recommend we bump our minimum required version for the
test suite and development tools to Python 2.5.

Thoughts?

-Hyrum

--

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

[RFC] deprecate svn_wc APIs that use svn_delta_editor_t

Hey all,

We have Ev2 somewhere on the future horizon. This means that many APIs
are going to be rev'd to take the new editor type. We likely aren't
going to get them into 1.8, but I'd like to go ahead and deprecate the
appropriate interfaces in svn_wc. The client lib can switch to some
internal/private APIs for 1.8 and those internal APIs will get
revamped to Ev2 when appropriate (and remain internal).

This kind of follows our concept of "svn_wc isn't a good API for
public consumption; apps should stick to svn_client". By moving these
APIs to internal, it will give us better flexibility when we want to
revamp them.

I'd like to do the deprecation now, rather than later. There isn't any
particular technical reason, but Julian phrased it best: engineering
at a social level. Smoke out anybody that might be using these APIs,
determine their actual needs, and move them to potentially-new
svn_client APIs.

There are four svn_wc APIs that consume delta editors (diff, status,
switch, update). Each of these would be deprecated and grow a
corresponding new private API, and the singular caller in
libsvn_client would switch.

Any objections to this deprecation for the 1.8 release?

Cheers,
-g

disallow mixed-revision WC->{WC,URL} copies by default?

Recently we had a user in #svn who somehow managed to create a
copy that could not be committed because of out-of-dateness errors.

I am not exactly sure what the real cause of the problem was.
It could be worked around by using a URL as copy source. So it
is likely that mixed-revisionnes somehow interfered the commit.

It was pointed out that novice users may not realise that they
might be copying mixed-revision trees if they run
  svn copy DIR1 DIR2
in their working copy. Of course, mixed-revisions are explained
in chapter 2 of the book and should be considered basic knowledge.
But because mixed-revisionness is hard to notice (nothing except
'svn info' shows it), users often simply forget about it.

We added the --allow-mixed-revisions option to 'svn merge' in 1.7.
Would it make sense to make 'svn copy' require this option if the
copy source is a mixed-rev WC subtree, in 1.8?
This would make sure that WC->{WC,URL} copies produce, by default,
the same result as URL->URL copies (modulo local mods in the WC).

Failing svnrdump_tests.py#43 with 1.7.x on Windows (was: Re: 1.7.3 next week-ish?)

Having another look at this failure ...

So far, we know (anyone, correct me if I'm wrong):

- 'svnrdump load' in this test fails with: "svnrdump: E140001:
Unrecognized record type in stream". It seems the dumpfile contents of
the file D/H/psi is split incorrectly (property content is dumped
early, and text delta later).

- It only happens on Windows.

- It only happens with ra_serf (both 1.7.x. and trunk) talking to
mod_dav_svn from 1.7.x@>=1239697 (i.e. after backport of r1237720 and
r1239596 (stuff in mod_dav_svn/liveprops.c) from trunk).

- If 1.7.x is rolled back to before r1239697, the problem does not occur.

- The problem does not occur with mod_dav_svn from trunk, not even
when rolled back to (before or after) r1237720 or r1239596.

- So far, it has been reproduced by the buildbot svn-slik-w2k3-x64-ra,
by Stephen Butler, and by my own (32bit) WinXP box. Paul Burba doesn't
see the failure with his Windows build (debug and release).

I'm trying some more experiments. If anyone else has any ideas, shoot ...

--
Johan

Status of 1.7.3

[ starting a new thread, as the previous has been seriously hijacked ]

Is there any sense of closure on the serf+windows test failure on the
1.7.x branch?  My sense is that the failure does *not* expose a new
bug on the branch, but rather smokes out an existing one.  If that is
the case, I am not opposed with moving forward on a 1.7.3 release on
the branch as-is, though we'd need to make some kind of note about the
test failure (or quash it for the time being).

Given the above, I'm inclined to move forward and roll tarballs on
Friday, if nobody objects too loudly.

-Hyrum

--

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Re: svn commit: r1241733 - /subversion/trunk/subversion/libsvn_delta/compat.c

Error While Checking out Git Repository

[l10n] Translation status report for trunk r1241345

Translation status report for trunk <at> r1241345

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2081     192     308     271  ++++++++++++++++++++++++UU~~~~ooo
    es    2007     266     385     405  ++++++++++++++++++++++UUU~~~~~oooo
    fr    2271       2       7       1  +++++++++++++++++++++++++++++~
    it    1862     411     562     226  +++++++++++++++++++UUUUU~~~~~~oo
    ja    2001     272     447     651  ++++++++++++++++++++++UUU~~~~~ooooooo
    ko    2144     129     172      71  ++++++++++++++++++++++++++U~~~
    nb    2060     213     326     379  +++++++++++++++++++++++UUU~~~~oooo
    pl    2086     187     285     156  ++++++++++++++++++++++++UU~~~~o
 pt_BR    1829     444     578     218  +++++++++++++++++++UUUU~~~~~~~oo
    sv    1784     489     601     224  ++++++++++++++++++UUUUU~~~~~~~oo
 zh_CN    2245      28      16       1  +++++++++++++++++++++++++++++~
 zh_TW    1765     508     629     284  ++++++++++++++++++UUUUU~~~~~~~oo

[RFC] Inheritable Properties

Hi All,

There has long been a desire for Subversion to support some form of
inherited properties.  Recently, while discussing a potential solution
for server dictated configurations (see
http://svn.haxx.se/dev/archive-2012-01/0032.shtml), the idea of using
inheritable properties as an alternative approach was raised.  To that
end I put together an inherited properties design wiki, see
http://wiki.apache.org/subversion/InheritedProperties

Many of you have already seen this wiki and weighed in on the server
dictated config thread, but in the event you haven't please check it
out.  I'd like to move this forward or return to the original server
dictated config, so any questions, concerns, and/or suggestions are
greatly appreciated.

Thanks,

Paul