[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: branching 1.14.x

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 14 Mar 2020 13:51:39 +0100

On Sat, Mar 14, 2020 at 08:03:28AM -0400, Mark Phippard wrote:
> Personally, I do not care at all about experimental features and shelving. I
> would favor ripping it all out and let it come back in a future release if
> someone wants to finish and turn it into a feature that we are willing to
> support forever. Right now, I cannot foresee a scenario where this feature
> ever becomes finished. I do not see why we are even doing the work to include
> it. I realize ripping it out would be work that someone has to do too
> though.

I don't think asking "why are we even doing this" is helpful.

Let's be clear on why this happened: It's because of lack of funding for
Julian and most other developers, who were previously very active and now
have only very little amounts of time they can afford to spend on SVN.

It's not because this feature is a bad idea, or the work that's already
been put in wasn't any useful. It is because developing new features in
our current situation is very difficult. If we still had 1.7 era activity
levels with 10+ active developers, my guess is that the shelving feature
would have long been done and shipped.

To put things in perspective, look at the complexity of the problems
Julian has been dealing with:
https://blog.foad.me.uk/2020/03/02/svn-shelving-development-review/

Now Julian is already doing further voluntary work to address blockers for
the upcoming release. Discouraging this kind of activity now makes things
even worse. It implies we still haven't adjusted our expectations to the
reality that we are doing pure volunteer work. In a project which is
mostly consumed by companies to build products to make money, this new
reality is very hard to swallow. Even slightly pushing volunteer developers
the wrong way could mean losing them entirely.

> I do not fully understand the editor path bug. But if you are saying it
> cannot be fixed in an existing release because of API changes, then that
> sounds like the priority. Unless Bert has time, I am not sure where we get
> Windows help now though.

As far as I understand, the problem is that people need to quote their
editor commands in certain ways to prevent parts of filenames being
interpreted as commands by the shell. This has security implications.
See https://svn.apache.org/r1874057

The editor command is part of the configuration file. We can't change the
quoting rules in a patch release without breaking existing installations
because, according to our compatibility guidelines, users should be able
to switch freely between patch releases without having to change anything
other than the set of binaries they are using.

The open problem is that the new quoting code won't work on Windows, even
though it is using an APR-provided function to sanitize the filename.
From my point of view this is something that should be fixed in APR if
possible.

> Anyway, I have a small window here where I have been able to maybe get our
> SVN support updated from 1.8 to a newer version. 1.14 is the only one I am
> interested in, so I am hoping the release process starts soon.

That is good news! Does this mean you might be able to get some people
at CollabNet activated to look at some of the issues we still need to
solve before 1.14 can be released?
Received on 2020-03-14 13:51:56 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.