You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2019/06/14 13:26:41 UTC
Subversion's community health
The Subversion community has gradually become much less active. We have
reached the point where we are struggling to even put out a release.
Johan said I may quote his thoughts, so I will:
> Indeed, I was just wondering about the same thing, before I read your
> response, Julian. It's quite clear that things are getting more and
> more quiet . I feel the project is slowly dying ...
>
> Sometimes I try to give an issue a little push by summarizing it on
> the dev list, or by giving some ideas, but for me that's usually about
> all I can do (limited time, limited knowledge, ...). I'm not the only
> one of course. Sometimes, others give a little push as well, and with
> enough hands some things still get done. But lately, those little
> pushes seem to become more and more rare.
>
> Also: if Julian's funding stops, will we get another release out?
> Theoretically we can, of course, but will we?
>
> I'm not blaming anyone of course. We're all volunteers, time gets
> consumed by other things, motivations and priorities shift, ... But it
> makes me a little sad .
>
> Can we do something about it? Or is this just the way it is ... a
> normal project lifecycle of which we've reached the end? It's become
> old and un-sexy legacy software ... at least in the perception of the
> masses. Can we revive it, or give it a second life?
>
> .oO("Make Subversion sexy again" :-))
Is this a Bad Thing? It is not objectively bad that the development has
tailed off; that's simply what happens when a project moves on to its
"mature" stage in its life cycle. But it is causing some problems in
adapting to the "new normal".
We have reached the point where we are struggling to even put out a
release because not enough developers are volunteering to do the work
required. (A release, no matter how minor the changes, currently
requires reviewing, testing, voting, writing release notes, updating
other web pages, and so on. Some of the steps are mostly automated but
others are not.)
So, we might want to look at changing how we do releases. I have some
other thoughts too. But first, I'd like to invite others to speak up.
Anyone with constructive suggestions, please do share them. Please let
us not dwell on our sadness and criticism of what went before; let us
try to keep this thread focused on positive solutions for what to do next.
- Julian
Re: Subversion's community health
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Karl Fogel,
am Freitag, 14. Juni 2019 um 18:16 schrieben Sie:
> I just put out an informal Twitter poll to get a sense of how
> people are using Subversion these days:
> https://twitter.com/kfogel/status/1139559630059843586
> (Or at least, to get a sense of how Twitter users who happen to see
> my tweet are using Subversion these days :-) .)
Asking the same here and on the users list might make sense as well.
I pretty much have the same use case like you, mostly with deployment
to different customers using per-product SVN-repos. authz is simply
necessary for us to restrict customers access to only their own tags.
Additionally, the usage scenario of SVN better reflects what is needed
with my customers: It doesn't make sense to allow them things like
local branches to e.g. heavily customize the deployment and they
don't even want to do that. Instead, if they change configs or such,
that needs to be considered during updates anyway and SVN forces me to
do so. That's simply a service to the customers making their life a
bit easier.
Some of them don't even understand why they should commit simple
config changes using a reasonable log message for long term benefit,
so run into conflicts because of incompatible local changes from time
to time. Those customers wouldn't be able to work any better with e.g.
GIT and things like commit vs. push and stuff. Running lots of
different GIT-repos per product per-customer wouldn't make my life
easier as well.
I'm not necessarily such a big fan of local-only-branches possible
with GIT for companies as well, because in my opinion, everything
employees do should be available to the company mostly. Of course
people don't necessarily need to commit using SVN as well, but that's
refusing to work in the end.
OTOH, for OSS-libs and -apps, Git and GitHub make life a lot easier.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Subversion's community health
Posted by Karl Fogel <kf...@red-bean.com>.
Julian Foad wrote:
>Ah, yes -- I didn't mean to discourage anyone from just describing a
>problem; that can then help others seek a solution. [...]
One thing I wonder is how widely Subversion is in non-published trees, especially corporate trees.
For example, my company uses Subversion internally for our entire corporate tree. It has various advantages over Git in that role: the authz controls are such a huge win, you can version directories, you get real copy history, you can update log messages post facto (this has helped us on more than one occasion). While we don't use the path-locking features, some other companies do, presumably because they work with a lot of non-mergable documents.
I just put out an informal Twitter poll to get a sense of how people are using Subversion these days:
https://twitter.com/kfogel/status/1139559630059843586
(Or at least, to get a sense of how Twitter users who happen to see my tweet are using Subversion these days :-) .)
There's nothing wrong with software reaching maturity or even declining in use. Lifecycles happen. On the other hand, there might be untapped willingness out there to support Subversion maintenance and development. It's worth making a bit of effort to find out. Perhaps the model this project depended on for so many years -- a small number of tech companies choosing to pay maintainers as staff -- no longer works well, but some other model would work (e.g, something similar to what Tidelift.com is doing).
Best regards,
-Karl
Re: Subversion's community health
Posted by Julian Foad <ju...@apache.org>.
Mark Phippard wrote:
> Making a suggestion here is tough. [...]
Ah, yes -- I didn't mean to discourage anyone from just describing a
problem; that can then help others seek a solution. Thanks for sharing
the problem of building downstream from the frequent releases.
- Julian
Re: What comes after 1.12?
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Aug 20, 2019 at 3:06 PM Branko Čibej <br...@apache.org> wrote:
> On 20.08.2019 20:50, Paul Hammant wrote:
> > If you all developed on trunk (patchsets for trunk, or direct to it),
> > and had an automated CI build setup that tested all permutations in
> > parallel, and a merging bot that attempted to cherry-pick commits
> > marked as [BUGFIX] back to all supported release branches without
> > human intervention (and Apache-TM votes), then you might have
> > streamlined things. Such a bot shouldn't shit the bed if the
> > cherry-pick fails *
>
> Duh. We have all that, except for the automated backport because no-one
> sane believes the word of *one* person that some [BUGFIX] commit is
> actually a viable candidate for any particular release branch. This is
> all documented in our community guide, which you'd be well advised to
> read before pontificating.
>
Yes. Someone definitely needs to LOOK at the "[BUGFIX]" commit first!
Re: What comes after 1.12?
Posted by Branko Čibej <br...@apache.org>.
On 20.08.2019 20:50, Paul Hammant wrote:
> My DevOps consulting life (around how to get to Trunk-Based
> Development from some often ClearCase inspired branching model),
> starts with what release cadence are you at now, and what do you want
> to get to. Clients who are quartly want to get to monthly (and have
> less unplanned releases following each). Clients that are monthly want
> to get to weekly (same elimination on unplanned). Aaand clients that
> are weekky eye daily. Sure that's dev teams of 20-1000 in one repo,
> where change would firehose into the repo if it could,
>
> *I've not encountered an enterprise team that wanted to slow down
> release cadence.*
>
> Seems to me Svn's problems are 1) lack of committers, perhaps because
> 2) patch contributors don't feel it matches their smoother experience
> elsewhere, and because 3) running "the build" from zero is hard, and
> 4) tests in the build isn't a super uniform thing.
>
> If you all developed on trunk (patchsets for trunk, or direct to it),
> and had an automated CI build setup that tested all permutations in
> parallel, and a merging bot that attempted to cherry-pick commits
> marked as [BUGFIX] back to all supported release branches without
> human intervention (and Apache-TM votes), then you might have
> streamlined things. Such a bot shouldn't shit the bed if the
> cherry-pick fails *
Duh. We have all that, except for the automated backport because no-one
sane believes the word of *one* person that some [BUGFIX] commit is
actually a viable candidate for any particular release branch. This is
all documented in our community guide, which you'd be well advised to
read before pontificating.
-- Brane
Re: What comes after 1.12?
Posted by Paul Hammant <pa...@hammant.org>.
My DevOps consulting life (around how to get to Trunk-Based Development
from some often ClearCase inspired branching model), starts with what
release cadence are you at now, and what do you want to get to. Clients
who are quartly want to get to monthly (and have less unplanned releases
following each). Clients that are monthly want to get to weekly (same
elimination on unplanned). Aaand clients that are weekky eye daily. Sure
that's dev teams of 20-1000 in one repo, where change would firehose into
the repo if it could,
*I've not encountered an enterprise team that wanted to slow down release
cadence.*
Seems to me Svn's problems are 1) lack of committers, perhaps because 2)
patch contributors don't feel it matches their smoother experience
elsewhere, and because 3) running "the build" from zero is hard, and 4)
tests in the build isn't a super uniform thing.
If you all developed on trunk (patchsets for trunk, or direct to it), and
had an automated CI build setup that tested all permutations in parallel,
and a merging bot that attempted to cherry-pick commits marked as [BUGFIX]
back to all supported release branches without human intervention (and
Apache-TM votes), then you might have streamlined things. Such a bot
shouldn't shit the bed if the cherry-pick fails *
Of course you're stymied by a lack of a integrated patch consumption
technology. Gerrit and Rietveld were made in Mondrian's image, ten years
ago. That said GitHub and pull requests a few months later stole the
spotlight and have not relinquished it since. Julian's stash/shelve tech
is the start of a standardized Pull-Request system for Svn, but the vision
need to be expanded.
Meanwhile, Mononoke ** is pushing forward to monorepo-nirvana even if
Atlassian today declare that Mercurial support in BitBucket has an end
date.
* oh, the back-applying merge bot will work fine as long as no rename/move
refactorings happen in the Subversion tree. That's because Subversion can't
merge through rename (unlike Git and Mercurial - seamless). Perforce could
do it if you muck around with branch-specs, but nobody does.
** Mononoke (a Rust backend for Mercurial) is hosted on GitHub (Git). The
dev eam feels no shame from that, perhaps because it's a periodical copy
from the same source-tree inside Facebook (and isn't currently buildable).
Git made a Svn compatibility for GitHub's Git repos - I wonder if future
contributors to Mononoke could too. Repo:
https://github.com/facebookexperimental/mononoke
Re: What comes after 1.12?
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> It looks like we need to make this clearer. Thank you for those
> suggestions. I will make some changes.
Changed:
http://subversion.apache.org/download
http://svn.apache.org/r1865613
* download.html
Add a notice of latest LTS release after notice of latest regular
release.
(#recommended-release): Change the title to "Latest regular release".
State the support period.
(#supported-releases): Change the title to "LTS releases".
State the support period.
Say "1.10 LTS" instead of just "1.10", and for 1.9, everywhere.
Please do let me know any other improvements you can think of!
- Julian
Re: What comes after 1.12?
Posted by Julian Foad <ju...@foad.me.uk>.
Thomas Singer wrote:
> What are the LTS releases?
See https://subversion.apache.org/roadmap.html#release-planning
> Is this somehow detectable by a user from the
> name? Ubuntu, for example, adds "LTS" to the name of their releases,
> e.g. "18.04 LTS". Maybe at
>
> <https://subversion.apache.org/download.cgi?update=201708081800>
>
> the title "Other Supported Release(s)" should rather be "LTS-Releases"
> with obvious indication how long they will receive support. And, of
> course, 1.10 should be named 1.10 LTS.
It looks like we need to make this clearer. Thank you for those
suggestions. I will make some changes.
- Julian
Re: What comes after 1.12?
Posted by Thomas Singer <th...@syntevo.com>.
What are the LTS releases? Is this somehow detectable by a user from the
name? Ubuntu, for example, adds "LTS" to the name of their releases,
e.g. "18.04 LTS". Maybe at
<https://subversion.apache.org/download.cgi?update=201708081800>
the title "Other Supported Release(s)" should rather be "LTS-Releases"
with obvious indication how long they will receive support. And, of
course, 1.10 should be named 1.10 LTS.
Tom
On 21/08/2019 09:07, Julian Foad wrote:
> Thomas Singer wrote:
>>> Probably the thing that would help me the most would be if
>>> the releases slowed down. If we want them on a schedule then do it
>> every 12
>>> months instead of 6.
>>
>> +1
>
> But... we are doing releases on a 24-month schedule. We are calling those "LTS" releases. They correspond in purpose and stability and frequency to the old minor releases.
>
> What is compelling you to do anything with the new "regular" 6-month releases in between LTS releases?
>
> Or did we not communicate sufficiently about the new release schedule?
> - Julian
>
Re: What comes after 1.12?
Posted by Julian Foad <ju...@apache.org>.
Thomas Singer wrote:
>> Probably the thing that would help me the most would be if
>> the releases slowed down. If we want them on a schedule then do it
>every 12
>> months instead of 6.
>
>+1
But... we are doing releases on a 24-month schedule. We are calling those "LTS" releases. They correspond in purpose and stability and frequency to the old minor releases.
What is compelling you to do anything with the new "regular" 6-month releases in between LTS releases?
Or did we not communicate sufficiently about the new release schedule?
- Julian
Re: What comes after 1.12?
Posted by Thomas Singer <th...@syntevo.com>.
> Probably the thing that would help me the most would be if
> the releases slowed down. If we want them on a schedule then do it every 12
> months instead of 6.
+1
--
Thomas
Re: What comes after 1.12?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 21, 2019 at 6:47 AM Stefan Sperling <st...@elego.de> wrote:
> On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote:
> > In my specific scenario with Subclipse things are just hard and I do not
> > think anything can be done to help. Since the native libraries for the
> API
> > we need lives outside of our control we always have a problem of the
> > version to support. I cannot just live on the latest version when the
> > major Unix distros are on older versions etc. Any solution is
> > complicated. I do not think TortoiseSVN, as a counter example, has these
> > problems at all. And the frequent releases I believe have historically
> > been good for that client to have.
>
> So it sounds like we can stick to the current release model after all?
>
> Short of fixing JavaHL API issues somehow (with class loaders or whatever),
> Subclipse could choose to be compatible with LTS releases only, could it
> not?
> This seems to be what some Linux distributions are doing now. I don't
> recall
> any other downstream projects raising concerns over our new release model.
>
This got sidetracked by me bringing up Subclipse. Yeah I more or less plan
to just declare support for the LTS version. That said, this only really
might work because the WC format has not changed. If it does, then all bets
are off. TortoiseSVN is always going to use the latest version (and
should). On Windows, everyone has that installed which means their WC
format will be upgraded and that would mean all of their SVN clients also
need to be on that version.
As noted in the other thread, other than the work involved (which is an
issue), Subclipse has no technical problem supporting the latest version on
Windows. It just then creates problems for all the other OS where the user
maybe does not have that version and has to jump through hoops to install
the right older version for their OS.
> I would not want to change the release model again after such a short time
> frame. As long as we can manage to stick to the new schedule I think we
> should stick to it. Should we find that there is nothing to release after
> 6 months we can just skip or postpone a release. Should the schedule turn
> out
> to be unworkable in the long term we will have to change it again in any
> case.
>
As I have said, I think the project should do whatever is best for the
project. I get how frequent releases may be the best way to attract new
contributors. That said, so far it has not done that and in my case and
perhaps others, it may be driving me away from the project faster than I
otherwise would. New releases create a lot of downstream activity that I am
not always prepared to do and which forces me to weigh whether to continue
at all. Dealing with a bunch of questions about "where is 1.12" etc. when
I know the release does not offer anything worth installing just makes me
consider walking away. As long as the project thinks it is getting value
from these releases, that is fine though.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: What comes after 1.12?
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote:
> In my specific scenario with Subclipse things are just hard and I do not
> think anything can be done to help. Since the native libraries for the API
> we need lives outside of our control we always have a problem of the
> version to support. I cannot just live on the latest version when the
> major Unix distros are on older versions etc. Any solution is
> complicated. I do not think TortoiseSVN, as a counter example, has these
> problems at all. And the frequent releases I believe have historically
> been good for that client to have.
So it sounds like we can stick to the current release model after all?
Short of fixing JavaHL API issues somehow (with class loaders or whatever),
Subclipse could choose to be compatible with LTS releases only, could it not?
This seems to be what some Linux distributions are doing now. I don't recall
any other downstream projects raising concerns over our new release model.
I would not want to change the release model again after such a short time
frame. As long as we can manage to stick to the new schedule I think we
should stick to it. Should we find that there is nothing to release after
6 months we can just skip or postpone a release. Should the schedule turn out
to be unworkable in the long term we will have to change it again in any case.
Re: What comes after 1.12?
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 20, 2019 at 11:46 AM Julian Foad <ju...@apache.org> wrote:
> Julian Foad wrote:
> > [...] OR
> >
> > * Each version can add APIs but cannot remove or break existing APIs?
> > (Like our current rules for minor releases.)
>
> Reading back what I've just written, it seems I'm completely missing
> something. If we take that approach (API changes allowed), then
> everything I wrote doesn't seem to amount to anything that would make a
> real difference to you.
>
> Can you clarify the source of the difficulties you experience, and what
> we could change that would help?
>
I do not have any specific recommendations. I would say first and foremost
do what we think is best for this project and might help attract more
contributions. Probably the thing that would help me the most would be if
the releases slowed down. If we want them on a schedule then do it every 12
months instead of 6. Maybe do more patch releases in between if we want to
get non API changes delivered sooner.
As I said before, I understand the idea behind frequent releases. That
said, with so little activity happening I am not in favor of us doing
releases because the calendar says we have to. If there is nothing worthy
of a release why are we pushing them so hard when it creates all of this
work for our community.
In my specific scenario with Subclipse things are just hard and I do not
think anything can be done to help. Since the native libraries for the API
we need lives outside of our control we always have a problem of the
version to support. I cannot just live on the latest version when the
major Unix distros are on older versions etc. Any solution is
complicated. I do not think TortoiseSVN, as a counter example, has these
problems at all. And the frequent releases I believe have historically
been good for that client to have.
Sorry not much help.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: What comes after 1.12?
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 20, 2019 at 7:04 PM Branko Čibej <br...@apache.org> wrote:
> On 20.08.2019 17:46, Julian Foad wrote:
> > Julian Foad wrote:
> >> [...] OR
> >>
> >> * Each version can add APIs but cannot remove or break existing
> >> APIs? (Like our current rules for minor releases.)
> >
> > Reading back what I've just written, it seems I'm completely missing
> > something. If we take that approach (API changes allowed), then
> > everything I wrote doesn't seem to amount to anything that would make
> > a real difference to you.
>
> I suspect that the real issue is that a consumer of JavaHL cannot
> trivially rely on compile-time version checks to decide which version of
> the API to use (and, as a consequence, which features it can expose). In
> Java, you have to do this with class loaders and other unspeakable
> horrors. So relying on the 1.8 *API* makes a kind of sense, since we do
> promise backwards compatibility on that level.
>
At the Java source code level, yes we just write to the 1.8 API and that
works fine. The problem is delivery. We have to include that JavaHL "jar"
part of the API with Subclipse and that has to match the native libraries
because of how JNI works. We cannot use the 1.8 JAR with native libraries
from a newer version. Consequently, we have to provide Eclipse plugins for
each SVN version that delivers the right java part. This is not too bad,
the problem is the user experience in Eclipse. Its UI naturally wants to
encourage the user to install the latest version and so usually the user
runs into problems, hits a forum and maybe figures out how to uninstall the
plugin and install the right version for their native libraries. The whole
thing sucks.
On Windows, we are able to provide the Java and the native due to some
hacks we are able to exploit in how DLL's are loaded and how JNI works.
There is no equivalent that works for other OS and something about the way
JNI loads libraries makes a static build not an option either. If it were
possible for us to deliver the native libraries then there would be less of
an issue. Anyway, I am several years past the point where I would have had
enough time and interest to try to make it all work again anyway if an
option were possible.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: What comes after 1.12?
Posted by Branko Čibej <br...@apache.org>.
On 20.08.2019 17:46, Julian Foad wrote:
> Julian Foad wrote:
>> [...] OR
>>
>> * Each version can add APIs but cannot remove or break existing
>> APIs? (Like our current rules for minor releases.)
>
> Reading back what I've just written, it seems I'm completely missing
> something. If we take that approach (API changes allowed), then
> everything I wrote doesn't seem to amount to anything that would make
> a real difference to you.
I suspect that the real issue is that a consumer of JavaHL cannot
trivially rely on compile-time version checks to decide which version of
the API to use (and, as a consequence, which features it can expose). In
Java, you have to do this with class loaders and other unspeakable
horrors. So relying on the 1.8 *API* makes a kind of sense, since we do
promise backwards compatibility on that level.
-- Brane
Re: What comes after 1.12?
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> [...] OR
>
> * Each version can add APIs but cannot remove or break existing APIs?
> (Like our current rules for minor releases.)
Reading back what I've just written, it seems I'm completely missing
something. If we take that approach (API changes allowed), then
everything I wrote doesn't seem to amount to anything that would make a
real difference to you.
Can you clarify the source of the difficulties you experience, and what
we could change that would help?
- Julian
What comes after 1.12?
Posted by Julian Foad <ju...@apache.org>.
I'm going to quote a big chunk of what Mark wrote.
Mark Phippard wrote in "Subversion's community health":
> [...] I feel like the current release
> policy is the only realistic way to encourage contributions to the
> product because there are known and predictable release vehicles to
> deliver those contributions. That said, those contributions are not
> coming and the frequent releases themselves ARE causing pain. You list
> some of it here.
>
> As maintainer of Subclipse, the releases are an enormous problem for
> me. The realities of the JavaHL API and JNI make it very difficult to
> support multiple releases. At the Java API level it is all quite easy
> the problem is in the delivery and just the details of
> Subclipse/Eclipse/Java and the OS and native libraries. I will not go
> into the details it is just that this situation creates a lot of bad
> options to choose from and has made things difficult to the point where
> I have to consider if it would not be better to just abandon the project.
This makes me feel so out of touch. I didn't realize it was such a pain
and I want Subversion to be a pleasure to package, to integrate, and to
work with for downstream consumers.
I know that's a big wish at this stage (with so much baggage and inertia
behind us) but let's try to make a change for the better.
> In general, I would rather see us spend more effort supporting the
> current release and only ever have another new 1.x release when some
> significant new features were fully realized. Even if that means there
> is never another new 1.x release.
When we decided to switch to faster releases we were looking almost
entirely from the perspective of developing new features and
improvements. But, as you say, this isn't happening.
Now that we recognize the gear shift to stabilization, I think this
makes it possible for us to decide to change (again) the way we deliver
upgrades.
It makes sense to me that we should be releasing incremental
improvements to a stable version, without making changes that require
extra effort downstream. Mostly we already are making incremental
improvements. The missing piece is we need to understand how our release
strategy generates the extra effort, and how we can change to a way that
does not.
It's easy to get hung up on the importance of the version numbers
themselves, the idea that a minor version number versus a patch release
number is The Thing we need to change. Of course, we understand
technically that the numbers are not the thing: instead the policies
about API versioning and the packaging and other usage mechanisms we've
put in place are the two things that matter. So let's be flexible in our
thinking, willing to change the numbering and/or the policies and practices.
Let me throw out a starting suggestion.
First the easy parts...
* Make just one kind of release from now on.
- Frequency is, let's say, every 6 months (April and October), if
there has been any change at all no matter how small, plus optionally
extra releases in between if and when we find it important and have the
resources to do so.
- We'll have to choose what version numbering to use. Either keep
the minor number at "1.12" from now on and increment the patch release
number, or just increment the minor number (1.13.0, 1.14.0, ...) and
don't use patch release numbers any more. But let's not focus on this
question initially because it unduly influences our thinking about the
meaning of new releases. Instead let's come back to this one after we've
decided the policies.
* Emphasis on stability.
- For each change we have already added in 1.12 compared with 1.10
LTS that is not a stable incremental improvement/fix, such as the
client-side shelving feature that is still "experimental", make it
opt-in so that users looking for long term stability don't see it, while
users looking for feature upgrades can set a config option and see it.
- Still allow contributions of feature development that is not
strictly incremental and stable, on condition that it's opt-in and
doesn't compromise stability otherwise.
And now the hard part...
What do we need to do with regard to API versioning, server protocol
version, etc. to make smooth consumption of upgrades?
* API changes must be strictly backwards- and forwards-compatible?
(Like our current rules for patch releases.)
- but that seems too restrictive
OR
* Each version can add APIs but cannot remove or break existing APIs?
(Like our current rules for minor releases.)
Can we solve the main issues for you with something like this?
> I am pretty happy with SVN 1.8.x and that is still the only version I
> run on servers. If SVN would slow down on new 1.x releases and was
> going to just iterate fixes on the current release I might be more
> inclined to move to it. But right now, on the server, it is just change
> for change sake. There are some fixes but none that are super important
> to me.
Well, I'm not sure what to make of your concern about the direction of
development, but if we now take a stabilization approach to future
releases, is this looking like we can make a better way forward?
Can anyone familiar with OS packaging, or other downstream uses, comment
as well?
- Julian
Re: Subversion's community health
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jun 14, 2019 at 9:26 AM Julian Foad <ju...@apache.org> wrote:
> The Subversion community has gradually become much less active. We have
> reached the point where we are struggling to even put out a release.
>
> Johan said I may quote his thoughts, so I will:
> > Indeed, I was just wondering about the same thing, before I read your
> > response, Julian. It's quite clear that things are getting more and
> > more quiet . I feel the project is slowly dying ...
> >
> > Sometimes I try to give an issue a little push by summarizing it on
> > the dev list, or by giving some ideas, but for me that's usually about
> > all I can do (limited time, limited knowledge, ...). I'm not the only
> > one of course. Sometimes, others give a little push as well, and with
> > enough hands some things still get done. But lately, those little
> > pushes seem to become more and more rare.
> >
> > Also: if Julian's funding stops, will we get another release out?
> > Theoretically we can, of course, but will we?
> >
> > I'm not blaming anyone of course. We're all volunteers, time gets
> > consumed by other things, motivations and priorities shift, ... But it
> > makes me a little sad .
> >
> > Can we do something about it? Or is this just the way it is ... a
> > normal project lifecycle of which we've reached the end? It's become
> > old and un-sexy legacy software ... at least in the perception of the
> > masses. Can we revive it, or give it a second life?
> >
> > .oO("Make Subversion sexy again" :-))
>
> Is this a Bad Thing? It is not objectively bad that the development has
> tailed off; that's simply what happens when a project moves on to its
> "mature" stage in its life cycle. But it is causing some problems in
> adapting to the "new normal".
>
> We have reached the point where we are struggling to even put out a
> release because not enough developers are volunteering to do the work
> required. (A release, no matter how minor the changes, currently
> requires reviewing, testing, voting, writing release notes, updating
> other web pages, and so on. Some of the steps are mostly automated but
> others are not.)
>
> So, we might want to look at changing how we do releases. I have some
> other thoughts too. But first, I'd like to invite others to speak up.
>
> Anyone with constructive suggestions, please do share them. Please let
> us not dwell on our sadness and criticism of what went before; let us
> try to keep this thread focused on positive solutions for what to do next.
>
>
Making a suggestion here is tough. I feel like the current release policy
is the only realistic way to encourage contributions to the product because
there are known and predictable release vehicles to deliver those
contributions. That said, those contributions are not coming and the
frequent releases themselves ARE causing pain. You list some of it here.
As maintainer of Subclipse, the releases are an enormous problem for me.
The realities of the JavaHL API and JNI make it very difficult to support
multiple releases. At the Java API level it is all quite easy the problem
is in the delivery and just the details of Subclipse/Eclipse/Java and the
OS and native libraries. I will not go into the details it is just that
this situation creates a lot of bad options to choose from and has made
things difficult to the point where I have to consider if it would not be
better to just abandon the project.
In general, I would rather see us spend more effort supporting the current
release and only ever have another new 1.x release when some significant
new features were fully realized. Even if that means there is never
another new 1.x release.
I am pretty happy with SVN 1.8.x and that is still the only version I run
on servers. If SVN would slow down on new 1.x releases and was going to
just iterate fixes on the current release I might be more inclined to move
to it. But right now, on the server, it is just change for change sake.
There are some fixes but none that are super important to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion's community health
Posted by Simon <si...@me.com>.
An interesting if slightly sad read. I want to add my support and praise
as a long-time user of Subversion.
I still come across many users out there. Subversion is thriving in one
particular business I work with. The youngsters have brought some Git in
with them but it seems to be led by fashion than anything else.
Subversion remains.
I choose Subversion over all other options for my own personal projects.
I like the simplicity and clarity.
I was recently considering some git-svn monster to allow local branching
on a big Subversion-hosted project but then I discovered the svn
shelving experiments. The checkpointing addition changes everything. I
cannot overstate that. I feel it's important to fully release
shelving/checkpointing and publicise the shift that it brings to working
with Subversion.
Of course, none of this magically brings new developers to the project
but perhaps it will provide motivation.
S.
On 2019/06/14 13:26:41, Julian Foad <j....@apache.org> wrote:
> The Subversion community has gradually become much less active. We
have >
> reached the point where we are struggling to even put out a release.>
>
> Johan said I may quote his thoughts, so I will:>
> > Indeed, I was just wondering about the same thing, before I read
your>
> > response, Julian. It's quite clear that things are getting more and>
> > more quiet . I feel the project is slowly dying ...>
> > >
> > Sometimes I try to give an issue a little push by summarizing it on>
> > the dev list, or by giving some ideas, but for me that's usually
about>
> > all I can do (limited time, limited knowledge, ...). I'm not the
only>
> > one of course. Sometimes, others give a little push as well, and
with>
> > enough hands some things still get done. But lately, those little>
> > pushes seem to become more and more rare.>
> > >
> > Also: if Julian's funding stops, will we get another release out?>
> > Theoretically we can, of course, but will we?>
> > >
> > I'm not blaming anyone of course. We're all volunteers, time gets>
> > consumed by other things, motivations and priorities shift, ... But
it>
> > makes me a little sad .>
> > >
> > Can we do something about it? Or is this just the way it is ... a>
> > normal project lifecycle of which we've reached the end? It's
become>
> > old and un-sexy legacy software ... at least in the perception of
the>
> > masses. Can we revive it, or give it a second life?>
> > >
> > .oO("Make Subversion sexy again" :-))>
>
> Is this a Bad Thing? It is not objectively bad that the development
has >
> tailed off; that's simply what happens when a project moves on to its
>
> "mature" stage in its life cycle. But it is causing some problems in >
> adapting to the "new normal".>
>
> We have reached the point where we are struggling to even put out a >
> release because not enough developers are volunteering to do the work
>
> required. (A release, no matter how minor the changes, currently >
> requires reviewing, testing, voting, writing release notes, updating >
> other web pages, and so on. Some of the steps are mostly automated but
>
> others are not.)>
>
> So, we might want to look at changing how we do releases. I have some
>
> other thoughts too. But first, I'd like to invite others to speak up.>
>
> Anyone with constructive suggestions, please do share them. Please let
>
> us not dwell on our sadness and criticism of what went before; let us
>
> try to keep this thread focused on positive solutions for what to do
next.>
>
> - Julian>
>
>
Re: Subversion's community health
Posted by Thomas Singer <th...@syntevo.com>.
I agree to all you wrote. But the increased speed of releasing new
versions with unstable experimental features somehow contradicts the
otherwise mature development state. As a user of the JavaHL API we only
consider a feature as stable if it is reflected in all binding APIs, too.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
https://www.syntevo.com
https://www.syntevo.com/blog
On 2019-06-14 16:34, Eric S. Raymond wrote:
> Julian Foad <ju...@apache.org>:
>> Anyone with constructive suggestions, please do share them. Please let us
>> not dwell on our sadness and criticism of what went before; let us try to
>> keep this thread focused on positive solutions for what to do next.
>
> You guys know me. I'm a past contributor, occasional critic, often a
> supporter. I did my best to push back when Linus Torvalds accused this
> crew of incompetence. And I, too, have had the recent experience of
> watching a project I was hugely invested in - GPSD - slide into a
> semi-active maintainence mode.
>
> The main piece of advice I have for all of you is that you should
> keep your expectations about Subversion's future realistic.
>
> The brute fact is that git has taken over the version-control world.
> It has stomped flat a couple of sttempts to compete with it in DVCS -
> Mercurial, bzr, monotone. And Subversion is at a massive disdavantage
> relative to *any* DVCS for reasons that should be too obvious to
> need repeating.
>
> Does Subversion have a future at all? I think the answer is "Yes",
> but it's not an exciting, sexy future. You guys have only two selling
> points I can see for new installations (1) Subversion's UI is
> *massively* simpler than git's, and (2) some customers have
> political/cultural reasons to prefer a centralized VCS with
> repositories that can't be easily cloned.
>
> I think that's enough for survival. But it's not exciting, not sexy,
> and not a recipe for drawing in new development talent. Thus, if you try
> to plan for big things, you will almost certainly fail because you won't
> be able to collect the investment of developmen time required to
> realize them.
>
> What you *can* hope for is to ship occasional releases of high quality
> and maintain Subversion's deserved reputation as the best of the pre-DVCS
> version-control systems.
>
> This is what I mean by setting realistic expectations. It means gearing
> down - accepting that your release tempo is going to be low and your
> main goal is to keep the issue tracker relatively clean.
>
> This is where I am now with GPSD. I had to struggle a bit to accept it,
> but the truth is GPSD is mature software that doesn't have much of
> anything left to do in its application domain. In an important way,
> that is victory.
>
> I'll pitch in here myself; I have plans to collect some more information
> about the semantics of the dump format and add it to the documentation
> already in the source tree. Because I believe in finishing what I
> started and leaving behind artifacts that say "Damn, that guy was a
> pro."
>
> You can still have that kind of excellence. It's not a trivial thing.
>
Re: Subversion's community health
Posted by Paul Hammant <pa...@hammant.org>.
Three PRs out on GitHub for Subversion spanning years -
https://github.com/apache/subversion/pulls
^ "join in" versus "don't join" in is communicated via team welcoming,
curating, and consuming of PRs in this age. Sure, Julian's shelve tech is
the starting point of a PR system for Subversion itself, but that doesn't
mean Svn development can't take advantage of a workflow that millions of
devs have adopted today on GitHub. To say no to that *feels like* an
arbitrary policy.
Towards that in GitHub-land, people dread bug reports remaining unattended.
Issues in GH is turned off, of course. They also are put off by incomplete
READMEs. Ref https://www.makeareadme.com/ (I have made contribs to that)
and a few similar efforts. Lots to say on Svn's README.
Re: Subversion's community health
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jun 14, 2019 at 10:35 AM Eric S. Raymond <es...@thyrsus.com> wrote:
> Julian Foad <ju...@apache.org>:
> > not dwell on our sadness and criticism of what went before; let us try to
> > keep this thread focused on positive solutions for what to do next.
>
It's all a matter of publicity.
Git gets all the publicity because open source uses Git and open
source happens in public.
Subversion is applicable to business and other centrally organized
entities. Some do their work in public; most don't.
Subversion's centralized nature is actually a big strength in those
situations -- and while I can go on about its technical superiorities,
that's a subject for another thread. The point is that because there
is no publicity, you don't see it, and neither do potential users or
contributors.
To Make Subversion Sexy Again there is a need for visibility and
publicity -- Subversion evangelism.
It starts with this community changing its thinking TODAY from "we're
old and tired" to "we're sexy again."
Talk about Subversion. Not just here. Everywhere. With everyone. Raise
awareness about the strengths Subversion has today. Talk about
Subversion 2.0 and all the wonderful things in it. Yes, even though it
doesn't exist yet. Even if the present members of this community won't
be the ones implementing it. Talk is cheap, yet it's a powerful thing.
Every conversation increases the probability of piquing someone's
interests and is a step toward attracting the new blood this community
needs.
Re: Subversion's community health
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Julian Foad <ju...@apache.org>:
> Anyone with constructive suggestions, please do share them. Please let us
> not dwell on our sadness and criticism of what went before; let us try to
> keep this thread focused on positive solutions for what to do next.
You guys know me. I'm a past contributor, occasional critic, often a
supporter. I did my best to push back when Linus Torvalds accused this
crew of incompetence. And I, too, have had the recent experience of
watching a project I was hugely invested in - GPSD - slide into a
semi-active maintainence mode.
The main piece of advice I have for all of you is that you should
keep your expectations about Subversion's future realistic.
The brute fact is that git has taken over the version-control world.
It has stomped flat a couple of sttempts to compete with it in DVCS -
Mercurial, bzr, monotone. And Subversion is at a massive disdavantage
relative to *any* DVCS for reasons that should be too obvious to
need repeating.
Does Subversion have a future at all? I think the answer is "Yes",
but it's not an exciting, sexy future. You guys have only two selling
points I can see for new installations (1) Subversion's UI is
*massively* simpler than git's, and (2) some customers have
political/cultural reasons to prefer a centralized VCS with
repositories that can't be easily cloned.
I think that's enough for survival. But it's not exciting, not sexy,
and not a recipe for drawing in new development talent. Thus, if you try
to plan for big things, you will almost certainly fail because you won't
be able to collect the investment of developmen time required to
realize them.
What you *can* hope for is to ship occasional releases of high quality
and maintain Subversion's deserved reputation as the best of the pre-DVCS
version-control systems.
This is what I mean by setting realistic expectations. It means gearing
down - accepting that your release tempo is going to be low and your
main goal is to keep the issue tracker relatively clean.
This is where I am now with GPSD. I had to struggle a bit to accept it,
but the truth is GPSD is mature software that doesn't have much of
anything left to do in its application domain. In an important way,
that is victory.
I'll pitch in here myself; I have plans to collect some more information
about the semantics of the dump format and add it to the documentation
already in the source tree. Because I believe in finishing what I
started and leaving behind artifacts that say "Damn, that guy was a
pro."
You can still have that kind of excellence. It's not a trivial thing.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Subversion's community health
Posted by Julian Foad <ju...@apache.org>.
>> Paul Hammant wrote:
>>> Nobody is going to roll up to contribute to 1.x or 2.x Subversion if
>>> there is no copy-pasteable instructions for building on Mac, Win and
>>> Linux. And there's not - https://svn.apache.org/repos/asf/subversion
>>> /trunk/INSTALL - has no apt, nuget or homebrew advice [...]
That's a good suggestion for modernizing the 'INSTALL' instructions.
> My comment from 4 days ago about unconsumed pull requests?
Is noted. I agree it is a problem. I will re-open the thread I started
in January about that.
> Dockerized build templates would be great for a quickstart.
Moved to "Subject: Docker Svn build environment".
- Julian
Re: Docker Svn build environment [was: Subversion's community health]
Posted by Paul Hammant <pa...@hammant.org>.
People wanting to donate a feature or fix a bug with Subversion are
increasingly going to be happy with a Docker-based quick start. Most
F/OSS teams want tests too, and y'all are very strict there in that
regard, and someone who can write tests for your test-base covering
code for your codebase is most likely going to be super-OK with
Docker. Where that incentivized groups is left with pause for thought
is on the consumption of contributions and the schedule for seeing
consequential releases.
Now, there's another group who want to image machines and shove in
"latest released" Subversion. Their problem is downstream maintainers
of operating systems for one, and the lack of comprehensive
Svn-dev-team install instructions to overcome maintainer choices
secondarily. Ubuntu's at 19.04 now, and it's shipping Svn 1.10. The
Mac's homebrew is at 1.12 presently, but it is quite often months
behind. This group is happy to build from source (if that is reliable)
and would use any on-platform or cross-compilation script to target
the machine/OS they're interested in. They may not care to edit
source. They may even be happy to skip tests - they just want the
binaries in situ.
How much of the first group would not want to wait for releases, and
instead deploy unreleased versions of Subversion? Meaning they've
donated a patch, have some assurances that it is being accepted as it
meets standards, but don't want to wait any longer before
productionizing it to some level?
Re: Docker Svn build environment [was: Subversion's community health]
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jun 19, 2019 at 6:36 AM Julian Foad <ju...@apache.org> wrote:
> Some time within the past year I looked for the best available Docker
> deployment of Subversion and found this:
>
> https://github.com/elleFlorio/svn-docker
> "Lightweight Docker image to build a container running an SVN server"
>
> It might be helpful as a starting point for creating a dev environment.
>
>
This seems like it could be useful for some dev situations and making it
easier to run tests but I otherwise do not see the value in it. People on
Windows and OSX ultimately want binaries that will run on their OS. On
Linux you want something that will work natively on your distro. This will
do nothing to assist with that.
It would make it easier to throw together a patch and run the tests but
ultimately I would expect someone doing this would probably also want to
run with their version of the binary they built.
By all means, we could create this but we should not make the mistake of
believing it solves the main problems.
Mark Phippard
http://markphip.blogspot.com/
Re: Docker Svn build environment [was: Subversion's community health]
Posted by Julian Foad <ju...@apache.org>.
Some time within the past year I looked for the best available Docker
deployment of Subversion and found this:
https://github.com/elleFlorio/svn-docker
"Lightweight Docker image to build a container running an SVN server"
It might be helpful as a starting point for creating a dev environment.
- Julian
Docker Svn build environment [was: Subversion's community health]
Posted by Julian Foad <ju...@apache.org>.
Paul Hammant wrote:
> Michael Pilato wrote:
>> Paul Hammant wrote:
>>> Nobody is going to roll up to contribute to 1.x or 2.x Subversion if
>>> there is no copy-pasteable instructions for building on Mac, Win and Linux.
>> Is there an opportunity here for someone to whip up a Dockerized
>> development environment for Subversion? Volume mapped to local disk for
>> easy editing of source code in your tool of choice, but all the
>> dependencies and such present in the image? Just thinking out loud here...
>
> Dockerized build templates would be great for a quickstart. I might have
> one or two for Svn and if I de-hack them might be shareable. They'd be
> biased towards Linux for build/test/standup of course, but would be
> better than nothing.
That would be awesome. It could remove the biggest barrier to entry for
many developers.
Docker is a good choice for this, and I am convinced we'll get the best
outcome if we pool our resources into supporting one way well, so count
me in.
- Julian
Re: Subversion's community health
Posted by Paul Hammant <pa...@hammant.org>.
Dockerized build templates would be great for a quickstart. I might have
one or two for Svn and if I de-hack them might be shareable. They'd be
biased towards Linux for build/test/standup of course, but would be better
than nothing.
Re: Subversion's community health
Posted by Michael Pilato <cm...@collab.net>.
On 6/18/19 9:50 AM, Paul Hammant wrote:
> Nobody is going to roll up to contribute to 1.x or 2.x Subversion if
> there is no copy-pasteable instructions for building on Mac, Win and
> Linux. And there's not -
> https://svn.apache.org/repos/asf/subversion/trunk/INSTALL - has no
> apt, nuget or homebrew advice for people wanting to get into
> development of Svn.
Is there an opportunity here for someone to whip up a Dockerized
development environment for Subversion? Volume mapped to local disk for
easy editing of source code in your tool of choice, but all the
dependencies and such present in the image? Just thinking out loud here...
Re: Subversion's community health
Posted by Paul Hammant <pa...@hammant.org>.
Nobody is going to roll up to contribute to 1.x or 2.x Subversion if there
is no copy-pasteable instructions for building on Mac, Win and Linux. And
there's not - https://svn.apache.org/repos/asf/subversion/trunk/INSTALL -
has no apt, nuget or homebrew advice for people wanting to get into
development of Svn.
My comment from 4 days ago about unconsumed pull requests?
- Paul
AW: Subversion 2.0
Posted by Markus Schaber <m....@codesys.com>.
Hi,
> The future isn't written yet. It can be anything. And since this is the idea phase of Subversion 2.0, there's no need to worry about specifics, like how to solve particular coding problems or who specifically is going to write what. Right now is the time to dream, out loud. What is your dream version control system, if you could have it all? Why would it be that way?
> Subversion 2.0, The Idea Phase, now open for business. :-)
I want to make an adventurous suggestion.
And it's not a feature suggestion.
I think a 2.0 is the time to start this discussion, in parallel to the feature and architecture discussions.
I want to question whether C is the best programming language for the future.
It's proven that more modern languages have a better productivity ratio given fixed developer time: More functionality, less bugs, less security issues, in the same time.
My first suggestion is Rust. It produces efficient Code comparable to C/C++, and has spatial and temporal memory safety built in. It has a growing active community, and it's easy to interface with C code (which allows converting the code piece by piece, and also allows easy migration for clients by providing compatible interfaces).
More and more Projects are adopting or using Rust (e. G. Firefox, Sequoia PGP, npm, tilde, dropbox, yelp...). The new maintainers of Bzip2 are converting it to Rust. Some of those projects have written about how they keep compatible interfaces for their clients, and how they manage to detect type safety failures on the C side (at run time).
All major platforms are supported, and for a V2.0, it's allowed to think about dropping support for more exotic platforms.
Although I favor Rust, other "acceptable" languages in my very personal opinion which come to my mind are Go, Swift, Python, C#.
On the other hand, I'd strongly oppose against C++. It's overly complex for both programmers and compiler implementers, and it's complexity is growing every release.
Disclaimer: I'm a longtime fan of both Rust and SVN, but never actually implemented anything "real" myself in Rust. I'm also a longtime fan of Python, and my day job is in C#/.NET Core which improved a lot those days. I did C and C++ as my fulltime Job in ancient times, I am still following its evolution, and learned to hate it for reasons... :-)
Mit freundlichen Grüßen / Best regards
Markus Schaber
--
CODESYS Group
We software Automation.
CODESYS Development GmbH
A member of the CODESYS Group
Dipl.-Inf. Markus Schaber | Team Leader Automation Server
Tobias-Dannheimer-Str. 5 | 87439 Kempten | Germany
Tel. +49-831-54031-979
m.schaber@codesys.com | https://www.codesys.com
CODESYS Store: https://store.codesys.com
CODESYS Forum: https://forum.codesys.com
Geschäftsführer / CEOs: Dipl.-Inf. Dieter Hess, Dipl.-Inf. Manfred Werner
Handelsregister / Trade register: Kempten HRB 13379 | USt-IDNr. / Tax ID No.: DE 307355786
Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received
this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Re: Subversion 2.0
Posted by Branko Čibej <br...@apache.org>.
On 21.06.2019 17:05, Paul Hammant wrote:
>> building those ideas on the Subversion 1.x code base
> +1
>
>> Rust or Go
> +1. Rust doesn't yet target all the platforms that Subversion already
> targets. It will do though, there's something unstoppable about the
> Rust community. I commissioned Rust ports of Python pieces on UpWorks
> for fixed prices and have always been impressed. If you choose a
> "most depended on, and least depending, FIRST" strategy for flipping
> to Rust, you could methodically transition to Rust from C/C++ and keep
> shipping.
>
> If anything feels 2.x worthy, it's addressing the chatty nature of the
> HTTP wire api. I don't think there'd be any appetite for that though,
> as Greg Stein et al participated with the W3C to make HTTP 1.1
> (including WebDAV) in order to polish Svn's over-HTTP sid. And given
> that the there's zero community interest in revisiting the WebDAV
> spec, you'd be talking about a non-standard extension, and I'll be
> there's no interest in that here.
There may be. At the time, there was an expectation that WebDAV/DeltaV
would become ubiquitous. The idea that a Subversion client could talk to
any WebDAV or DeltaV server, and the obverse, was very exciting. But
that went the way of so many exciting ideas, and in the end, our
"HTTPv2" protocol ditched DeltaV entirely whilst playing only lip
service to WebDAV.
I think there's still a good reason to have an HTTP-based protocol, but
something more streamlined and stateful and -- possibly -- requiring
HTTP/2 features might be a better fit. And almost certainly something
that wasn't tied to Apache HTTPd on the server side.
-- Brane
Re: Subversion 2.0
Posted by Paul Hammant <pa...@hammant.org>.
> building those ideas on the Subversion 1.x code base
+1
> Rust or Go
+1. Rust doesn't yet target all the platforms that Subversion already
targets. It will do though, there's something unstoppable about the
Rust community. I commissioned Rust ports of Python pieces on UpWorks
for fixed prices and have always been impressed. If you choose a
"most depended on, and least depending, FIRST" strategy for flipping
to Rust, you could methodically transition to Rust from C/C++ and keep
shipping.
If anything feels 2.x worthy, it's addressing the chatty nature of the
HTTP wire api. I don't think there'd be any appetite for that though,
as Greg Stein et al participated with the W3C to make HTTP 1.1
(including WebDAV) in order to polish Svn's over-HTTP sid. And given
that the there's zero community interest in revisiting the WebDAV
spec, you'd be talking about a non-standard extension, and I'll be
there's no interest in that here.
-ph
Re: Subversion 2.0
Posted by Branko Čibej <br...@apache.org>.
On 29.07.2019 11:36, 钱海远(Nathan) wrote:
>
> Dear Develop Team,
>
>
>
> We have created a system for pre-commit review in our company (Force
> Review, or pre-commit hooks will reject commit), as shown below.
>
>
>
> But SVN does not support staging code area.
>
There's nothing wrong with using the uncommitted transaction as the
"staging code area," although the command-line client will probably try
to remove it after it times out, so you'd have to integrate the code
review logic with the client somehow.
Or you could use temporary branches: the code review logic could create
a commit on a temporary branch from the commit transaction, then reject
the commit. Once approved, the temporary branch would be merged back to
the original commit target. Or you could save the transaction itself and
then replay it locally.
In any case I doubt that you really need support from core Subversion
for this. If you can implement master/master replication, surely you can
also implement some kind of "pre" commit review workflow. You don't need
Subversion 2.0 for that.
-- Brane
Re: Subversion 2.0
Posted by Paul Hammant <pa...@hammant.org>.
The "shelve" functionality in Subversion may be grown into a "continuous
review" system in the future. If you can't wait that long Rhodecode and
Assembla both give Subversion a code review capability today and would be
able to migrate your existing repo to their tech/service. Various CollabNet
products may do so too.
- Paul
答复: Subversion 2.0
Posted by "钱海远 (Nathan)" <qi...@hikvision.com>.
Dear Develop Team,
We have created a system for pre-commit review in our company (Force Review, or pre-commit hooks will reject commit), as shown below.
But SVN does not support staging code area. Can it be developed in 2.0?
If we can have a staging area, we can build pre-commit action simple , such as pre-commit builds, check the quality of the code before it is committed. Now we are also implementing it in a similar way like FR , code consistency is difficult to judge, and user’s operation are complex.
[cid:image001.png@01D54632.FAD83480]
________________________________
Best Regards!
Haiyuan Qian
R & D Management Group
Hangzhou Hikvision Digital Technology Co.,Ltd
No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
M (86)18969199712
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
发件人: Nathan Hartman <ha...@gmail.com>
发送时间: 2019年7月3日 0:41
收件人: Markus Schaber <m....@codesys.com>
抄送: Thomas Singer <th...@syntevo.com>; Subversion Developers <de...@subversion.apache.org>
主题: Re: Subversion 2.0
On Fri, Jun 28, 2019 at 12:51 PM Markus Schaber <m....@codesys.com>> wrote:
It's a very powerful feature, on par or even superior to other (D)VCSes - as long as we manage to keep the interface clear enough that users can handle everything.
I'm always astonished how complicated GIT can be for seemingly "simple" tasks, and even the available GUIs are not always helpful. HG is doing a much better job here, as far as I can see...
It stand and falls with the user interface.
And we should take it seriously from the beginning. When the new features are implemented with unusable/complex UI first, users will want to try it, fail, and turn away. We won't be able to catch them later when the UI is better...
I agree. A bad user interface will result in complaints that repeat
around the Internet in perpetuity, even after the problems are fixed.
I think we know this from experience! Also, once the interface gets
"grandfathered in," it can't / won't change because of compatibility.
I'm studying this issue and I'll be back with some concrete
suggestions; in the meantime I'd love to hear your thoughts as well!
Especially use cases. :-)
________________________________
CONFIDENTIALITY NOTICE:
This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
Re: Subversion 2.0
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jun 28, 2019 at 12:51 PM Markus Schaber <m....@codesys.com>
wrote:
> It's a very powerful feature, on par or even superior to other (D)VCSes -
> as long as we manage to keep the interface clear enough that users can
> handle everything.
>
> I'm always astonished how complicated GIT can be for seemingly "simple"
> tasks, and even the available GUIs are not always helpful. HG is doing a
> much better job here, as far as I can see...
>
> It stand and falls with the user interface.
>
> And we should take it seriously from the beginning. When the new features
> are implemented with unusable/complex UI first, users will want to try it,
> fail, and turn away. We won't be able to catch them later when the UI is
> better...
I agree. A bad user interface will result in complaints that repeat
around the Internet in perpetuity, even after the problems are fixed.
I think we know this from experience! Also, once the interface gets
"grandfathered in," it can't / won't change because of compatibility.
I'm studying this issue and I'll be back with some concrete
suggestions; in the meantime I'd love to hear your thoughts as well!
Especially use cases. :-)
AW: Subversion 2.0
Posted by Markus Schaber <m....@codesys.com>.
Hi, Nathan,
Von: Nathan Hartman <ha...@gmail.com>
> Let's put our "future caps" on...
> Imagine a fully-functioning checkpointing feature:
[...]
> How does the future look so far? :-)
Looks very bright for me! :-)
It's a very powerful feature, on par or even superior to other (D)VCSes - as long as we manage to keep the interface clear enough that users can handle everything.
I'm always astonished how complicated GIT can be for seemingly "simple" tasks, and even the available GUIs are not always helpful. HG is doing a much better job here, as far as I can see...
It stand and falls with the user interface.
And we should take it seriously from the beginning. When the new features are implemented with unusable/complex UI first, users will want to try it, fail, and turn away. We won't be able to catch them later when the UI is better...
Mit freundlichen Grüßen / Best regards
Markus Schaber
--
CODESYS Group
We software Automation.
________________________________________
CODESYS Development GmbH
A member of the CODESYS Group
Dipl.-Inf. Markus Schaber | Team Leader Automation Server
Tobias-Dannheimer-Str. 5 | 87439 Kempten | Germany
Tel. +49-831-54031-979
mailto:m.schaber@codesys.com | https://www.codesys.com
CODESYS Store: https://store.codesys.com
CODESYS Forum: https://forum.codesys.com
Geschäftsführer / CEOs: Dipl.-Inf. Dieter Hess, Dipl.-Inf. Manfred Werner
Handelsregister / Trade register: Kempten HRB 13379 | USt-IDNr. / Tax ID No.: DE 307355786
________________________________________
Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received
this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Re: Checkpointing
Posted by Branko Čibej <br...@apache.org>.
On 30.06.2019 16:56, Nathan Hartman wrote:
> On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej <brane@apache.org
> <ma...@apache.org>> wrote:
>
> As Mark explained, it will do none of the above unless someone
> steps up
> and writes the code.
>
> For reference, what Nathan described was discussed here on the
> list and
> in person during hackathons years ago, yet nothing happened until
> Julian
> started writing code (and even then, what Julian is doing is a limited
> subset of the "ideal").
>
> If there's no interest amongst people to take the time to write
> the code
> ... well, we can all tell tall stories about the future, but that
> won't
> change it one bit.
>
>
> I know.
>
> We all know.
>
> I understand the frustration I see here.
>
> I understand that you've seen these wonderful discussions time and
> again and then nothing happened. And you've seen it so many times that
> you've become inoculated to the idea that it could change.
>
> But it will change, because:
>
> There was a wise man named Albert Einstein, and I have no idea if he
> actually said this or not but he's widely credited with saying that
> the definition of insanity is to do the same thing over and over and
> expect different results.
>
> Telling the closed dev@ community that we need new developers didn't
> work until now and I don't expect it to start working miraculously.
> I'm sorry to use an expletive -- marketing -- but that's what we need
> with the outside world. No business can sustain itself without telling
> the world what it's all about and there's no reason to believe that an
> open source project is any different. There's still a profit motive.
> In a business, it's profit in money; in an open source project, it's
> profit in mindshare and participation. So we need to get out there and
> drum up some new business, BUT:
>
> There's a bit of a chicken and egg problem here. If we entice new
> potential devs to join dev@ and they come here and see discussions of
> decline, defeat, and despair,
Who's despairing? Stating facts is neither decline, defeat, nor despair. :)
I would actually love to see all of you who are so enthusiastic in this
thread to come aboard. Especially as one of the things the developers
here were traditionally lacking is real-world user experience on
non-trivial projects (I count Subversion itself as "trivial" in terms of
the complexity of our version control workflow).
> they'll get turned off and go somewhere
> else. People want to be part of something successful! We need those
> who join to see discussions of all the cool things Subversion WILL do.
>
> Of course it won't do any of it until after the code gets written. For
> the code to get written we need devs. To get devs we need to change
> our thinking from despair to planning for a great future. So let's have
> some positive discussions over here!
>
> I'm going to search for those old discussions -- and the ones about
> what the command line syntax should be like -- and I'll be back later
> with some concrete thoughts.
Perfect.
-- Brane
Re: Checkpointing
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej <br...@apache.org> wrote:
> As Mark explained, it will do none of the above unless someone steps up
> and writes the code.
>
> For reference, what Nathan described was discussed here on the list and
> in person during hackathons years ago, yet nothing happened until Julian
> started writing code (and even then, what Julian is doing is a limited
> subset of the "ideal").
>
> If there's no interest amongst people to take the time to write the code
> ... well, we can all tell tall stories about the future, but that won't
> change it one bit.
>
I know.
We all know.
I understand the frustration I see here.
I understand that you've seen these wonderful discussions time and
again and then nothing happened. And you've seen it so many times that
you've become inoculated to the idea that it could change.
But it will change, because:
There was a wise man named Albert Einstein, and I have no idea if he
actually said this or not but he's widely credited with saying that
the definition of insanity is to do the same thing over and over and
expect different results.
Telling the closed dev@ community that we need new developers didn't
work until now and I don't expect it to start working miraculously.
I'm sorry to use an expletive -- marketing -- but that's what we need
with the outside world. No business can sustain itself without telling
the world what it's all about and there's no reason to believe that an
open source project is any different. There's still a profit motive.
In a business, it's profit in money; in an open source project, it's
profit in mindshare and participation. So we need to get out there and
drum up some new business, BUT:
There's a bit of a chicken and egg problem here. If we entice new
potential devs to join dev@ and they come here and see discussions of
decline, defeat, and despair, they'll get turned off and go somewhere
else. People want to be part of something successful! We need those
who join to see discussions of all the cool things Subversion WILL do.
Of course it won't do any of it until after the code gets written. For
the code to get written we need devs. To get devs we need to change
our thinking from despair to planning for a great future. So let's have
some positive discussions over here!
I'm going to search for those old discussions -- and the ones about
what the command line syntax should be like -- and I'll be back later
with some concrete thoughts.
Re: Checkpointing
Posted by Branko Čibej <br...@apache.org>.
On 28.06.2019 19:12, Thomas Singer wrote:
> Hi Nathan,
>
> Thanks for your explanation. This sounds quite interesting. I have
> some questions though:
>
> - so the working copy can have checked out multiple commits or one
> checkpoint?
>
> - will it support multiple histories ("branches") planned, e.g. for
> different features?
>
> - will it support "rebasing" such a local history onto the latest
> updated commit?
>
As Mark explained, it will do none of the above unless someone steps up
and writes the code.
For reference, what Nathan described was discussed here on the list and
in person during hackathons years ago, yet nothing happened until Julian
started writing code (and even then, what Julian is doing is a limited
subset of the "ideal").
If there's no interest amongst people to take the time to write the code
... well, we can all tell tall stories about the future, but that won't
change it one bit.
-- Brane
Re: Checkpointing
Posted by Thomas Singer <th...@syntevo.com>.
Imagine working on one larger feature (or even multiple features). You
already have created a couple of local commits, but are not yet
finished. Following use cases come to my mind:
1) some other developer commits new revisions
- it should be possible to continue working on your feature-queue
keeping it based on the old revision, but sooner or later it comes the
time to integrate the new revision(s)
- this means to create a new queue on the new revision and cherry-pick
all local commits of the old queue onto this new revision (could this be
done with purely local information or would each cherry-pick require a
possibly slow communication with the server?)
- with each cherry-pick, a conflict might occur - aborting should abort
the creation of the new queue and application of the old queue,
resulting in the deletion of the partly finished new queue keeping the
old one
- each queue should be rebased independently onto the new revisions
2) you have to make a quick-fix revision
- you need to switch from your local feature-queue to the latest
revision and fix the bug a coworker requests to get fixed
- you may now switch back to your queue to proceed with the work, but
there is a new revision now, so you should base your work sooner or
later on that revision
3) you want to rework your local commits, e.g. change order, squash some
commits, change the message
- create a new queue based on the same revision
- create new local commits by cherry-picking commits from the other
(old) queue, maybe amending some local commits
- after the new queue is ready (verify to diff it with the old queue)
the old queue can be deleted
- often enough I find it useful to be able to make one of my first
feature commits public, so the x first local commits should be possible
to be become revisions => the queue becomes shorter and based on the new
revision(s)
4) you need to fork an existing queue at any local commit
- switching to one of the local commits of your current queue you detect
that it contains a flaw
- creating now a local commit to fix would mean to first create a new
queue based on the same revision, apply all previous local commits (no
conflict risk) - the old queue would be kept
It might be useful to be able to "store" somehow one or another queue on
the server, e.g. for backup reasons, so no change is lost if my hard
disk crashes or my code fails and cleans the disk. (Creating a new, real
feature branch with revisions in the repository I don't like because
then they would be cut in stone and this would force me to create nice
and clean commits. But because we are not without error, such code will
contain back and forth changes and hence hard to read.)
As long as I'm working on a non-trivial feature/refactoring, I prefer to
have complete control over my commits, I even like to commit completely
unstable and incomplete code with Git - because I have the possibility
to clean up later.
--
Best regards,
Thomas Singer
On 02/07/2019 18:32, Nathan Hartman wrote:
> On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer <th...@syntevo.com>
> wrote:
>
>> With "rebasing" I mean, that such list of "local commits" needs to be
>> re-applied (on demand, not automatically) onto a different revision.
>> Something like a continues series of cherry-picking (with the
>> possibility to get a conflict in each step; and a possibility to
>> continue after conflict resolution or abort). This means to me, that at
>> least cherry-picking needs to be possible from a revision or a "local
>> commit".
>>
>
> Could you describe how you would like to use this capability? E.g.,
> give an example use case?
>
Re: Checkpointing
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer <th...@syntevo.com>
wrote:
> With "rebasing" I mean, that such list of "local commits" needs to be
> re-applied (on demand, not automatically) onto a different revision.
> Something like a continues series of cherry-picking (with the
> possibility to get a conflict in each step; and a possibility to
> continue after conflict resolution or abort). This means to me, that at
> least cherry-picking needs to be possible from a revision or a "local
> commit".
>
Could you describe how you would like to use this capability? E.g.,
give an example use case?
Re: Checkpointing
Posted by Thomas Singer <th...@syntevo.com>.
Hi Nathan,
Thanks for your detailed answers.
>> - will it support "rebasing" such a local history onto the latest
>> updated commit?
>
>
> It will have to support "rebasing" which is what "svn update" already
> does today. Otherwise you couldn't commit your work!
With "rebasing" I mean, that such list of "local commits" needs to be
re-applied (on demand, not automatically) onto a different revision.
Something like a continues series of cherry-picking (with the
possibility to get a conflict in each step; and a possibility to
continue after conflict resolution or abort). This means to me, that at
least cherry-picking needs to be possible from a revision or a "local
commit".
Tom
Re: Checkpointing
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jun 28, 2019 at 1:12 PM Thomas Singer <th...@syntevo.com>
wrote:
> - so the working copy can have checked out multiple commits or one
> checkpoint?
>
The working copy has always provided one "view." I say "view" for lack
of a better word but I mean the checked out directory of your data
that is under version control. Currently, that "view" can be changed
through updating to a different revision, switching to a different
branch, changing depth on a sparse/shallow checkout, etc; but it's
still one view. As I imagine it, checkpoints would add the ability to
update to a checkpoint, or revert to the last checkpoint.
This begs a few important questions, such as:
When someone does "svn revert" with no additional parameters, what are
we reverting to? Do we revert to BASE as we always have? Or to the
last checkpoint? That requires further study...
> - will it support multiple histories ("branches") planned, e.g. for
> different features?
>
Subversion already provides server-side branches. For local work,
earlier I described multiple "arrays" of checkpoints. We need a better
name than "array" but the idea is that a checkpoint is like a local
commit, and the array is a local linear history of such commits. And
you can have multiple arrays. You could say that each array is like a
local branch. But I would rather think of each array as being for a
certain subject. So, for example if I'm editing code to write a new
feature, I might have a checkpoint array called "feature" and a second
checkpoint array called "unrelated" just as an example. I'd work on my
feature, making checkpoints to the "feature" array as I go. Suppose
that while I'm working I come across typos in comments. I could fix
those typos and make a checkpoint of that un the "unrelated" array.
When I'm ready to commit, I'll commit the typo fixes separately from
the feature work. That would make it much easier to have one subject
per commit.
Anyway that's how I imagine it. If you have other thoughts, I'd love
to hear them!
- will it support "rebasing" such a local history onto the latest
> updated commit?
It will have to support "rebasing" which is what "svn update" already
does today. Otherwise you couldn't commit your work!
Re: Checkpointing
Posted by Thomas Singer <th...@syntevo.com>.
Hi Nathan,
Thanks for your explanation. This sounds quite interesting. I have some
questions though:
- so the working copy can have checked out multiple commits or one
checkpoint?
- will it support multiple histories ("branches") planned, e.g. for
different features?
- will it support "rebasing" such a local history onto the latest
updated commit?
--
Best regards,
Thomas Singer
Re: Subversion 2.0
Posted by Mark Phippard <ma...@gmail.com>.
> On Jun 28, 2019, at 12:29 PM, Nathan Hartman <ha...@gmail.com> wrote:
>
>> On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer <th...@syntevo.com> wrote:
>
>> What I like most about Git:
>> - it allows to create clean commits, because I can modify all my local
>> commits, e.g. reorder and squash them, in case I detected an error in a
>> previous, unpushed commit
> <snip>
>> - I can solve every conflict locally, try again and again, without
>> losing any changes (imagine a complicated merge in SVN where you now
>> have solved a couple of conflicts, but an update brings new conflicts)
> <snip>
>> - Git allows me to create a feature in my own branch, turn all my
>> commits in this branch up-side-down if I need (even after pushing to the
>> repository) and finally rebase it on top of the main development branch
>
> Let's put our "future caps" on...
>
> Imagine a fully-functioning checkpointing feature:
>
> Checkpointing is a "local commit history" mechanism, but we don't call
> it a "commit" because "commit" is a strong concept in Subversion.
> Commit history is immutable: Whatever is committed is safe forever.
>
> A checkpoint is a weak concept, more like the weak commit history you
> find in a DVCS. Checkpoints are local and private until committed or
> shared.
>
> A checkpoint can represent any committable changes. Checkpoints can be
> rewritten, modified, reordered, copied, moved, squashed, divided,
> deleted, etc. Their commit messages can be edited easily.
>
> Checkpoints live in arrays of checkpoints. Each array has a user-
> assigned descriptive name and serves as a mutable linear mini-history.
> Arrays can be copied, renamed, deleted... You can have as many arrays
> as you like.
>
> Checkpoints and arrays of checkpoints can be created and manipulated
> by the system or the user.
>
> By the System:
>
> Automatic checkpoint before potentially destructive operation: If
> there are uncommitted changes in the WC, svn update and svn merge
> automatically create a checkpoint. That way, the user never loses a
> good working state to a bad one if the update, merge, or ensuing
> conflict resolution get messed up (by either the system or user).
> You can try again and again until you get it right.
>
> Automatic checkpoint at specified time intervals: This one is more
> applicable to GUI clients. You can tell it to make an automatic
> checkpoint, say, every 15 minutes, if there are new changes. Better
> yet, the GUI client could monitor the directory / get OS change
> notifications and make an automatic checkpoint of every change. So
> when you hit "save" in your editor, Subversion makes a checkpoint as
> well. Automatically.
>
> By the User:
>
> Reordering/rewriting/manipulating means you can work happily and make
> checkpoints along the way, ending up with a "messy" checkpoint
> history. You can rewrite/reorder checkpoints in place. Or, if you like
> "non-destructive editing," create a new separate array and cherrypick
> checkpoints onto it, making any edits. If you worked on different
> unrelated things, create different unrelated arrays and cherrypick
> each checkpoint onto the appropriate array. Once you've built up a
> clean linear history of related changes in a checkpoint array, that
> array can either be squashed and committed as one commit or left
> intact and committed as a sequence of commits. GUI clients could
> utilize Subversion's lock-modify-unlock feature to make the separate
> commits in order without other unrelated commits getting in the
> middle. In the future, a new improved client/server protocol will
> support committing an array of checkpoints as a sequence of commits,
> atomically. So either all the checkpoints go in or none go in, and
> nothing gets in the middle.
>
> Pull requests: A mechanism to pack up an array of checkpoints in a
> single file for sharing with colleagues. No big paragraph needed to
> explain this one.
>
> How does the future look so far? :-)
I'd maybe welcome the feature but it wouldn't change much for me as this was never an area of SVN where I felt much pain. For me the problem would be that this is all still built upon a base that does not handle merging or moved files very well. Problems that would mean this feature would also likely suffer from those weaknesses when trying to reconcile your local checkpoints with what has happened upstream as you are pulling in updates. While I can see how this could also aid in the code review options, I think the fact that the Git model is based on reviewing actual commits is still superior because the commit you review is the one that you know is merged/accepted. For this feature it is still just a form or reviewing a patch and there is no real way to verify that what you reviewed is what was merged. At minimum, those are problems that would still need to be solved to claim we are nearing parity with what Git can offer here.
More importantly, I still think this is a question that is bigger than features. For the community to become healthy we need something that is going to bring 5-10 regular contributors or maybe a smaller number if there is a big increase in short term contributors. This shelving/checkpointing idea/feature has been around for years. There has been some interest in trying the work in progress but it has not brought in anyone to actually contribute. There has not even been many comments to emails on the proposals that Julian has made.
While it is great to be excited about what the product might look like AFTER someone does all of this work the real question needs to be what is going to draw in more people to contribute. I am not sure there is anything that will do this.
Mark
Re: Subversion 2.0
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer <th...@syntevo.com>
wrote:
> What I like most about Git:
>
- it allows to create clean commits, because I can modify all my local
> commits, e.g. reorder and squash them, in case I detected an error in a
> previous, unpushed commit
>
<snip>
> - I can solve every conflict locally, try again and again, without
> losing any changes (imagine a complicated merge in SVN where you now
> have solved a couple of conflicts, but an update brings new conflicts)
>
<snip>
> - Git allows me to create a feature in my own branch, turn all my
> commits in this branch up-side-down if I need (even after pushing to the
> repository) and finally rebase it on top of the main development branch
>
Let's put our "future caps" on...
Imagine a fully-functioning checkpointing feature:
Checkpointing is a "local commit history" mechanism, but we don't call
it a "commit" because "commit" is a strong concept in Subversion.
Commit history is immutable: Whatever is committed is safe forever.
A checkpoint is a weak concept, more like the weak commit history you
find in a DVCS. Checkpoints are local and private until committed or
shared.
A checkpoint can represent any committable changes. Checkpoints can be
rewritten, modified, reordered, copied, moved, squashed, divided,
deleted, etc. Their commit messages can be edited easily.
Checkpoints live in arrays of checkpoints. Each array has a user-
assigned descriptive name and serves as a mutable linear mini-history.
Arrays can be copied, renamed, deleted... You can have as many arrays
as you like.
Checkpoints and arrays of checkpoints can be created and manipulated
by the system or the user.
By the System:
Automatic checkpoint before potentially destructive operation: If
there are uncommitted changes in the WC, svn update and svn merge
automatically create a checkpoint. That way, the user never loses a
good working state to a bad one if the update, merge, or ensuing
conflict resolution get messed up (by either the system or user).
You can try again and again until you get it right.
Automatic checkpoint at specified time intervals: This one is more
applicable to GUI clients. You can tell it to make an automatic
checkpoint, say, every 15 minutes, if there are new changes. Better
yet, the GUI client could monitor the directory / get OS change
notifications and make an automatic checkpoint of every change. So
when you hit "save" in your editor, Subversion makes a checkpoint as
well. Automatically.
By the User:
Reordering/rewriting/manipulating means you can work happily and make
checkpoints along the way, ending up with a "messy" checkpoint
history. You can rewrite/reorder checkpoints in place. Or, if you like
"non-destructive editing," create a new separate array and cherrypick
checkpoints onto it, making any edits. If you worked on different
unrelated things, create different unrelated arrays and cherrypick
each checkpoint onto the appropriate array. Once you've built up a
clean linear history of related changes in a checkpoint array, that
array can either be squashed and committed as one commit or left
intact and committed as a sequence of commits. GUI clients could
utilize Subversion's lock-modify-unlock feature to make the separate
commits in order without other unrelated commits getting in the
middle. In the future, a new improved client/server protocol will
support committing an array of checkpoints as a sequence of commits,
atomically. So either all the checkpoints go in or none go in, and
nothing gets in the middle.
Pull requests: A mechanism to pack up an array of checkpoints in a
single file for sharing with colleagues. No big paragraph needed to
explain this one.
How does the future look so far? :-)
Re: Unicode composable characters on macOS [was: Subversion 2.0]
Posted by Thomas Singer <th...@syntevo.com>.
Hi Branko,
Thanks for the detailed explanation. Would you mind to add the
description to the linked issue and mark it as
resolved/works-for-me/no-bug, so this information is not lost?
--
Best regards,
Thomas Singer
=============
syntevo GmbH
On 26/06/2019 17:39, Branko Čibej wrote:
> On 26.06.2019 10:40, Marc Strapetz wrote:
>> On 25.06.2019 23:35, Branko Čibej wrote:> On 25.06.2019 19:15, Thomas
>> Singer wrote:
>>>> What I don't like:
>>>> - after more than a decade the umlaut problem of composed/decomposed
>>>> UTF-8 has not been solved
>>>
>>> It has, actually, in Apple's APFS, where the fix belongs.
>>
>> That sounds interesting. Just to be sure, you are referring to this
>> problem:
>>
>> https://issues.apache.org/jira/browse/SVN-2464
>>
>> ? It would be great to have some more information for which OSX
>> version and which file systems the problem should be resolved.
>
>
> The original problem was that Apples HFS+ filesystem normalized paths to
> Unicode Normalisation Form D. In practice that meant that if you created
> a file with a name that contained a composable character, then read that
> name from the filesystem, you could get different results (i.e., the
> name was "the same" as far as Unicode normalisation is concerned, but
> the actual representation bytes were different).
>
> The new APFS filesystem (which is the default in the last two versions
> of macOS, IIRC) doesn't do that any more.
>
> This is on local disk, which is APFS:
>
> brane@zulu:~/src/svn/test$ svnadmin create repo
> brane@zulu:~/src/svn/test$ svn co file://$(pwd)/repo wc
> Checked out revision 0.
> brane@zulu:~/src/svn/test$ touch wc/čibej
> brane@zulu:~/src/svn/test$ svn add wc/čibej
> A wc/čibej
> brane@zulu:~/src/svn/test$ svn st wc/
> A wc/čibej
>
> and this is on an HFS+ disk image:
>
> brane@zulu:/Volumes/hfs$ svnadmin create repo
> brane@zulu:/Volumes/hfs$ svn co file://$(pwd)/repo wc
> Checked out revision 0.
> brane@zulu:/Volumes/hfs$ touch wc/čibej
> brane@zulu:/Volumes/hfs$ svn add wc/čibej
> A wc/čibej
> brane@zulu:/Volumes/hfs$ svn st wc/
> ? wc/čibej
> ! wc/čibej
>
> The second instance clearly shows that the filesystem changed the file name.
>
> -- Brane
>
>
Unicode composable characters on macOS [was: Subversion 2.0]
Posted by Branko Čibej <br...@apache.org>.
On 26.06.2019 10:40, Marc Strapetz wrote:
> On 25.06.2019 23:35, Branko Čibej wrote:> On 25.06.2019 19:15, Thomas
> Singer wrote:
>>> What I don't like:
>>> - after more than a decade the umlaut problem of composed/decomposed
>>> UTF-8 has not been solved
>>
>> It has, actually, in Apple's APFS, where the fix belongs.
>
> That sounds interesting. Just to be sure, you are referring to this
> problem:
>
> https://issues.apache.org/jira/browse/SVN-2464
>
> ? It would be great to have some more information for which OSX
> version and which file systems the problem should be resolved.
The original problem was that Apples HFS+ filesystem normalized paths to
Unicode Normalisation Form D. In practice that meant that if you created
a file with a name that contained a composable character, then read that
name from the filesystem, you could get different results (i.e., the
name was "the same" as far as Unicode normalisation is concerned, but
the actual representation bytes were different).
The new APFS filesystem (which is the default in the last two versions
of macOS, IIRC) doesn't do that any more.
This is on local disk, which is APFS:
brane@zulu:~/src/svn/test$ svnadmin create repo
brane@zulu:~/src/svn/test$ svn co file://$(pwd)/repo wc
Checked out revision 0.
brane@zulu:~/src/svn/test$ touch wc/čibej
brane@zulu:~/src/svn/test$ svn add wc/čibej
A wc/čibej
brane@zulu:~/src/svn/test$ svn st wc/
A wc/čibej
and this is on an HFS+ disk image:
brane@zulu:/Volumes/hfs$ svnadmin create repo
brane@zulu:/Volumes/hfs$ svn co file://$(pwd)/repo wc
Checked out revision 0.
brane@zulu:/Volumes/hfs$ touch wc/čibej
brane@zulu:/Volumes/hfs$ svn add wc/čibej
A wc/čibej
brane@zulu:/Volumes/hfs$ svn st wc/
? wc/čibej
! wc/čibej
The second instance clearly shows that the filesystem changed the file name.
-- Brane
Re: Subversion 2.0
Posted by Marc Strapetz <ma...@syntevo.com>.
On 25.06.2019 23:35, Branko Čibej wrote:> On 25.06.2019 19:15, Thomas
Singer wrote:
>> What I don't like:
>> - after more than a decade the umlaut problem of composed/decomposed
>> UTF-8 has not been solved
>
> It has, actually, in Apple's APFS, where the fix belongs.
That sounds interesting. Just to be sure, you are referring to this problem:
https://issues.apache.org/jira/browse/SVN-2464
? It would be great to have some more information for which OSX version
and which file systems the problem should be resolved.
-Marc
On 25.06.2019 23:35, Branko Čibej wrote:
> On 25.06.2019 19:15, Thomas Singer wrote:
>> What I don't like:
>> - after more than a decade the umlaut problem of composed/decomposed
>> UTF-8 has not been solved
>
> It has, actually, in Apple's APFS, where the fix belongs.
>
> -- Brane
>
>
Re: Subversion 2.0
Posted by Branko Čibej <br...@apache.org>.
On 25.06.2019 19:15, Thomas Singer wrote:
> What I don't like:
> - after more than a decade the umlaut problem of composed/decomposed
> UTF-8 has not been solved
It has, actually, in Apple's APFS, where the fix belongs.
-- Brane
Re: Subversion 2.0
Posted by Thomas Singer <th...@syntevo.com>.
What I like with SVN:
- it is easy to fix commit messages
- the externals are easy to understand
- the properties
- the file locking
What I don't like:
- after more than a decade the umlaut problem of composed/decomposed
UTF-8 has not been solved
What I like most about Git:
- it allows to create clean commits, because I can modify all my local
commits, e.g. reorder and squash them, in case I detected an error in a
previous, unpushed commit
- it is still much stronger merging renamed, modified files
- I can solve every conflict locally, try again and again, without
losing any changes (imagine a complicated merge in SVN where you now
have solved a couple of conflicts, but an update brings new conflicts)
- I can switch branches very quickly back and forth without the need to
transfer the whole project over a network (even having to wait a couple
of minutes with a decent connection is too slow if you are used to Git's
seconds - we are not talking about the fact that it is wasted energy to
transfer the same data again and again just because SVN does not cache it)
- Git allows me to create a feature in my own branch, turn all my
commits in this branch up-side-down if I need (even after pushing to the
repository) and finally rebase it on top of the main development branch
Of course, the latter only works fine if there is just one developer of
this feature branch, but usually this is the case for me. More than 5
years ago we have massively refactored our products to switch from one
GUI library to another (Swing -> SWT). Without Git and rebasing this
would have been much more complicated.
Most of the things I like in Git are not possible with other DVCS, or
require some non-standard extensions, or may produce weird states you
don't know how to get out.
I don't know what SVN 2 would need to have, so I would consider to use
it for a software product repository again.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
Re: Subversion 2.0
Posted by Paul Hammant <pa...@hammant.org>.
> [..] How can we leverage Subversion's centralized structure to give
> something _better_than modern workflows?
I'm the guy behind http://trunkbaseddevelopment.com and am predictably
going to say the workflow Svn needs to ace is trunk-based development.
That includes (since 2008) some mechanism for pull-requests. I think
the Svn team should only concentrate on command line capability for
that, and leave web UIs to the commercial teams - Assembla, RhodeCode,
CollabNet.
I also wrote something about Subversion on my blog a week or so ago -
lesser known strengths and weaknesses -
https://paulhammant.com/2019/06/14/merkle-trees-and-source-control/.
Sure, there's some other attempt at a comparison with
https://svnvsgit.com/, but that's not me.
-ph
Re: Subversion 2.0
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jun 21, 2019 at 10:38 AM Mark Phippard <ma...@gmail.com> wrote:
> I think the reason that both Subversion and Git were successful is that
> they both had very clear and compelling visions and goals for what they
> wanted to accomplish and then they did that.
>
> I do not think a few new features or design changes to Subversion will
> make a difference at this point .. and I am not saying that is what you are
> suggesting. I would want to be sold on some compelling new ideas for a
> product, and then probably why building those ideas on the Subversion 1.x
> code base makes sense.
>
Agreed 100%.
The purpose of this thread is to have a community-wide brainstorming
session to figure out exactly what we want from the Subversion of the
future, for that very reason.
As a cautionary tale I would look at Veracity.
> http://veracity-scm.com/compare/
>
> I struggle to find some of the original blog posts that Eric Sink made
> when they were creating this product but I know they set out to fix a lot
> of the shortcomings in Git and they did so using an Apache license. AFAIK,
> they accomplished most of their initial goals and then went on to also
> incorporate some of the ideas from Fossil in adding a distributed agile
> tracker and wiki to the product as well. Despite all of this the product
> landed with a thud and has been discontinued. Aside from wondering why it
> would not be a better code base than Subversion to start a new product from
> I come back to the compelling idea point. What are the ideas that are
> going to move the needle? Who is the target audience? The corporate world
> is probably still in play but it seems very difficult at this point to move
> the open source world away from Git.
>
I'm glad you brought that up because it's exactly what I want to
address today.
One of my goals for Subversion 2.0 is to attract new users and
developers to the project.
The obvious question is: How?
Git is the 800 pound gorilla in the version control room, so any
strategy to attract new users and developers to Subversion must deal
with Git (among other things).
Veracity SCM tried to be a better Git. One could argue that Mercurial
tried the same thing. But Git has been far more widely adopted, at
least it appears that way in public, in the open source world. We
don't know what goes on behind closed doors.
Mercurial could be perceived as a Git wanna-be. It's easier to use but
a little slower. Git blasted Mercurial out of the water because people
generally don't like imitations. People want the real deal. Given the
choice between real Git and imitation Git (even if it's not true; it's
perceived), most people will probably choose real Git.
That should give us a hint. The goal "be a better CVS" worked in 1999.
"Be a better Git" will _not_ work in 2019. So we have to go a
different way.
My suggestions for a strategy with respect to Git:
* Do not compete with Git in areas where Git is strong. Instead,
cooperate with Git in those areas.
* Compete with Git in areas where Git is weak.
Do not compete with Git: I do not suggest to turn Subversion into a
DVCS because we'll be perceived as imitation Git. Subversion is
centralized and that is NOT a weakness. I'd like to point out that in
2004, Internet access was slow and therefore "everything is local" was
a big selling point of Git. But in 2019, when broadband Internet is
cheap, when cell phone plans come with mobile hotspot, with 5G on the
horizon (and they're talking about massive amounts of data at near-
instant speeds), this is becoming much less of a concern with every
passing minute. People want to be on the same sheet of paper with each
other. People are comfortable with "the cloud." As telecommunications
get better and faster every day, Git's "everything is local" starts to
become more of a liability than an asset. GitHub exists because people
want and need a central repository. Like the saying goes, what's old
is new again.
Compete with Git: I suggest to start by amplifying the best things
about Subversion that make it different and better than Git. But
that's just incremental change. We need something more. As Mark said,
we need something compelling. So I will close for now with the
following question, which I have been asking myself: How can we
leverage Subversion's centralized structure to give something _better_
than modern workflows?
If we come up with some compelling ideas, it might be interesting to invite
> Eric to conversation to share what they learned and why what they were
> doing never worked. The one thing I can say is that while they were open
> source and tried to create a community and be open maybe there are things
> they could have done differently that would have had more impact ... such
> as trying to make it an Apache Foundation product.
>
I would like as many people as possible to be invited to the
conversation.
Re: Subversion 2.0
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jun 21, 2019 at 7:13 AM Nathan Hartman <ha...@gmail.com>
wrote:
> The future isn't written yet. It can be anything. And since this is the
> idea phase of Subversion 2.0, there's no need to worry about specifics,
> like how to solve particular coding problems or who specifically is going
> to write what. Right now is the time to dream, out loud. What is your dream
> version control system, if you could have it all? Why would it be that way?
>
> Subversion 2.0, The Idea Phase, now open for business. :-)
>
I think the reason that both Subversion and Git were successful is that
they both had very clear and compelling visions and goals for what they
wanted to accomplish and then they did that.
I do not think a few new features or design changes to Subversion will make
a difference at this point .. and I am not saying that is what you are
suggesting. I would want to be sold on some compelling new ideas for a
product, and then probably why building those ideas on the Subversion 1.x
code base makes sense.
As a cautionary tale I would look at Veracity.
http://veracity-scm.com/compare/
I struggle to find some of the original blog posts that Eric Sink made when
they were creating this product but I know they set out to fix a lot of the
shortcomings in Git and they did so using an Apache license. AFAIK, they
accomplished most of their initial goals and then went on to also
incorporate some of the ideas from Fossil in adding a distributed agile
tracker and wiki to the product as well. Despite all of this the product
landed with a thud and has been discontinued. Aside from wondering why it
would not be a better code base than Subversion to start a new product from
I come back to the compelling idea point. What are the ideas that are
going to move the needle? Who is the target audience? The corporate world
is probably still in play but it seems very difficult at this point to move
the open source world away from Git.
If we come up with some compelling ideas, it might be interesting to invite
Eric to conversation to share what they learned and why what they were
doing never worked. The one thing I can say is that while they were open
source and tried to create a community and be open maybe there are things
they could have done differently that would have had more impact ... such
as trying to make it an Apache Foundation product.
The one thing I will throw out is that I think a new version control
product will need to be written in Rust or Go to attract any attention, not
that I have any experience with either language. A product written in C is
not going to attract new developers - in my opinion.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 2.0
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Stefan Sperling <st...@apache.org>:
> Another useful feature would be built-in support for Git's fast-export
> streams in svnadmin dump/load.
That would be a very good idea. But not easy.
reposurgeon reads and understands Subversion dump files. If you want a running
start of fast import and fast export, look at that code.
If somebody on the ore team takes on the job I am willing to help.
Success would take a pretty large maintainence burden off me and. yes,
it really should live in svndump.
I can supply a bunch of useful end-to-end tests of this capability.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Subversion 2.0
Posted by Stefan Sperling <st...@apache.org>.
On Mon, Jun 24, 2019 at 04:24:46PM +0200, Branko Čibej wrote:
> 3. "This protocol is too chatty, let's invent a better one"
>
> Our wire protocol is a module. We can invent new ones without affecting
> existing ones. Likewise for repository storage, or working copy storage,
> etc. (with the latter actually being the hardest to change, due to
> hysterical ... um, I mean historical reasons).
>
Case in point: The ra-git branch started out as a repository access
module, and later evolved into a repository fliesystem backend.
Our design is flexible enough to allow for such features to be added.
Even something like 'Git-backed SVN' would not require a 2.x branch.
I would encourage new developers who want to work towards SVN 2.0
to gain some experience by finishing the ra-git branch and making a
new 1.x release with built-in Git compatibility. This would go a
long way towards allowing users to benefit from the advantages of
both SVN and Git. Many environments run a mix of SVN and Git today and
SVN will hopefully stay relevant for a longer period of time if it
co-operates.
Another useful feature would be built-in support for Git's fast-export
streams in svnadmin dump/load.
Git already has a reasonable level of SVN compatibility on their side.
Such compatibility being a one-way street is not nice for users of
either tool.
Re: Subversion 2.0
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Jun 30, 2019 at 4:47 AM Greg Stein <gs...@gmail.com> wrote:
> On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman <ha...@gmail.com>
> wrote:
>
>> I understand that from a technical perspective, there is no reason to
>> change the major version number unless compatibility/API/ABI promises are
>> going to be broken. A 2.0 means you can break those promises, BUT I propose
>> that just because you CAN do something doesn't mean you have to. Subversion
>> 2.0 could very well keep 100% of 1.x's promises.
>>
>
> That isn't how it works.
>
> Subversion 1.x is a signal to system administrators that they can upgrade
> their 1.x installations to the latest 1.x and NOT WORRY.
>
> Once you bring in 2.x, regardless of what the developers do to keep/lose
> compatibility ... you have lost the 20-year guarantee of compatibility. The
> admin must now do some research. And the question in that admin's head will
> always be "what am I missing? if this is compatible with 1.x, and I should
> not fear upgrading to 2.0 ... then why did they change the version number?
> that was supposed to be a signal."
>
> For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes
> no guarantee". You speak of "marketing". There is no amount of marketing
> that will alter the past 20 years of our API guarantees.
>
>
That is actually perfect.
There are several challenges here that need to be addressed.
One is the need for more developer participation. Working on that...
Another is that one of Subversion's strengths is also a weakness. The
20 year guarantee is great for system administrators and users. It
demonstrates stability and reliability, which is important given what
Subversion does. This isn't a video game; this software houses your
precious data! Years and years of forward and backward compatibility is
a bragging point and a strength.
But it's also a weakness because it means that we can't be bold and
experiment, as that would break guarantees and bring instability.
So, okay, that's a legitimate explanation as to why we don't up the
version number to 2.0 unnecessarily. But I still think we need the
*concept* of a 2.0 as a way of moving forward. So I'll alter what I
said before, slightly: Bug fixes, stability improvements, and stable
production-ready features should go into 1.x, while 2.0 should be the
playground for bold experiments, developers, and adventurous users.
It doesn't matter if there's ever a 2.0 release. Instead, as features
in 2.0 become stable and production-ready, they can be merged back to
1.x and become part of the next "no worries" 1.x release, provided
they do not break compatibility! If they break compatibility, then
we'll cross that bridge when we get to it.
So, yes, 1.x can live on and on, until 1.414213562373095.
For marketing purposes, we could give names to releases that introduce
major new (but stable and production-ready) functionality.
The important thing is: We want devs! So we do not want to create an
impression that bold new stuff isn't welcome. It's welcome and it has
a place called 2.0!!
Re: Subversion 2.0
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman <ha...@gmail.com>
wrote:
> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej <br...@apache.org> wrote:
> >On 25.06.2019 19:16, Thomas Singer wrote:
> >>> I don't want to rain on anyone's parade but here's some food for
> >>> thought. The only valid reason to call anything 2.0 is if, and only if,
> >>> we decide to break backwards compatibility in some area.
> >>
> >> I disagree. It is quite common use to name something 2.0 if it has
> >> serious improvements over 1.x.
> >
> >That's marketing, not software development. :)
>
> Subversion needs some marketing -- separately from and in addition to
> plans for a 2.0.
>
> I understand that from a technical perspective, there is no reason to
> change the major version number unless compatibility/API/ABI promises are
> going to be broken. A 2.0 means you can break those promises, BUT I propose
> that just because you CAN do something doesn't mean you have to. Subversion
> 2.0 could very well keep 100% of 1.x's promises.
>
That isn't how it works.
Subversion 1.x is a signal to system administrators that they can upgrade
their 1.x installations to the latest 1.x and NOT WORRY.
Once you bring in 2.x, regardless of what the developers do to keep/lose
compatibility ... you have lost the 20-year guarantee of compatibility. The
admin must now do some research. And the question in that admin's head will
always be "what am I missing? if this is compatible with 1.x, and I should
not fear upgrading to 2.0 ... then why did they change the version number?
that was supposed to be a signal."
For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes
no guarantee". You speak of "marketing". There is no amount of marketing
that will alter the past 20 years of our API guarantees.
Cheers,
-g
Re: Subversion 2.0
Posted by Nathan Hartman <ha...@gmail.com>.
>
> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej <br...@apache.org> wrote:
>On 25.06.2019 19:16, Thomas Singer wrote:
>>> I don't want to rain on anyone's parade but here's some food for
>>> thought. The only valid reason to call anything 2.0 is if, and only if,
>>> we decide to break backwards compatibility in some area.
>>
>> I disagree. It is quite common use to name something 2.0 if it has
>> serious improvements over 1.x.
>
>That's marketing, not software development. :)
Subversion needs some marketing -- separately from and in addition to plans
for a 2.0.
I understand that from a technical perspective, there is no reason to
change the major version number unless compatibility/API/ABI promises are
going to be broken. A 2.0 means you can break those promises, BUT I propose
that just because you CAN do something doesn't mean you have to. Subversion
2.0 could very well keep 100% of 1.x's promises. Even though the option to
break promises exists, I would err on the side of keeping them anyway,
unless doing so (very sparingly) would provide compelling benefits that
outweigh the hassle caused by such breakage.
So why 2.0 then?
(1) To separate between a stable 1.x that focuses on keeping a clean issue
tracker and a 2.0 that focuses on new and experimental development. This
might give more freedom to experiment while reducing risk of disruption to
existing customers until new features are release-quality.
(2) To make it clear, in light of 1.x "going stable," that the project
won't turn away new development or new developers. Both are encouraged and
invited with open arms, always.
(3) Marketing.
Just to make this clear, I do not think it's a good idea to reimplement
Subversion in another language and I do not think the nature of Subversion
should be changed drastically. That would be a different product. I'm in
favor of longevity: Longevity of the project, longevity of keeping
promises, backward/forward compatibility between server/client and on-disk
data structures, etc. The fact that a dump and load has NOT been needed in
many years, the fact that Subversion is careful about preserving your
history -- in short, Longevity, should be a bragging point of Subversion.
Somewhere you said that it took 4 years to get from nothing to 1.0. The
difference between today and back then is that today you have a rock solid,
reliable, excellent 1.x; back then you had CVS. There's no rush to release
2.0, or even write code for it. The journey of 1000 miles doesn't begin
with a single step; it begins with deciding where to go. :-)
Re: Subversion 2.0
Posted by Branko Čibej <br...@apache.org>.
On 25.06.2019 19:16, Thomas Singer wrote:
>> I don't want to rain on anyone's parade but here's some food for
>> thought. The only valid reason to call anything 2.0 is if, and only if,
>> we decide to break backwards compatibility in some area.
>
> I disagree. It is quite common use to name something 2.0 if it has
> serious improvements over 1.x.
That's marketing, not software development. :)
-- Brane
Re: Subversion 2.0
Posted by Thomas Singer <th...@syntevo.com>.
> I don't want to rain on anyone's parade but here's some food for
> thought. The only valid reason to call anything 2.0 is if, and only if,
> we decide to break backwards compatibility in some area.
I disagree. It is quite common use to name something 2.0 if it has
serious improvements over 1.x.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
Re: Subversion 2.0
Posted by Branko Čibej <br...@apache.org>.
On 21.06.2019 13:12, Nathan Hartman wrote:
> Subversion 1.x is mature, stable, rock-solid, reliable, and safe. The
> goal of 1.x is now stability and availability. Big changes and
> whiz-bang new features don't really belong there. It's time for
> Subversion 2.0, the Subversion of the future.
I don't want to rain on anyone's parade but here's some food for
thought. The only valid reason to call anything 2.0 is if, and only if,
we decide to break backwards compatibility in some area. Now sure we can
find more or less valid arguments to do that, but they have to be
weighed very carefully indeed. Remember that there's almost 20 years
worth of stable code and tests here; you don't throw that away without
due consideration. We should also keep in mind the many, many existing
servers and repositories. Any 2.0 will have to provide more than just an
upgrade path, it will have to keep all those repositories functional for
both 1.x and 2.x clients.
Here are some *not* valid reasons for 2.0:
1. Rewrite Subversion in another language
That's just not going to happen. Yes, we can write new code in
Rust/Go/D/Scala/whatever, *if* we decide that the whole world is winux
and *BSD and we don't care about legacy systems. But aiming to replace
the codebase with something new is the surest way to kill the project
that I can think of. We're not likely to attract new developers if we
plan to get bogged down for years without a major new release (remember,
it took us 4 years to get from nothing to 1.0).
2. "I don't like the way feature X is implemented, let's replace it with
something better"
I can certainly understand and even share that feeling. However: a) see
above under "20 years of stable code", and b) there are always ways to
make improvements in a backward-compatible way. As a user of software,
the thing I hate the most is when people gratuitously break API/ABI/UI
compatibility for no better reason than "it's better this way."
3. "This protocol is too chatty, let's invent a better one"
Our wire protocol is a module. We can invent new ones without affecting
existing ones. Likewise for repository storage, or working copy storage,
etc. (with the latter actually being the hardest to change, due to
hysterical ... um, I mean historical reasons).
-- Brane
Subversion 2.0
Posted by Nathan Hartman <ha...@gmail.com>.
I first heard about Subversion from an article in Linux Journal back in
2002 [1]. The only viable open source version control at the time was CVS,
which wasn't very good, but "everyone" used it because it was available and
it worked, despite its shortcomings. Subversion promised to be a massive
improvement over CVS and I could tell from the article that some serious
thought had gone into its design. By the time I finished reading, I was
really excited.
Next year the Subversion project turns 20. Subversion met and exceeded its
original goals by a lot. My personal experience has been many years of use,
ZERO problems, and Subversion's enterprise features are a big win.
Subversion 1.x is mature, stable, rock-solid, reliable, and safe. The goal
of 1.x is now stability and availability. Big changes and whiz-bang new
features don't really belong there. It's time for Subversion 2.0, the
Subversion of the future.
I have many thoughts to share in the coming days, including my observations
about the world of technology and why things happening right now mean there
are opportunities to attract new users and developers to the project.
But I won't be the only voice here. This post is only the first page of a
big conversation and everyone is encouraged to participate.
The future isn't written yet. It can be anything. And since this is the
idea phase of Subversion 2.0, there's no need to worry about specifics,
like how to solve particular coding problems or who specifically is going
to write what. Right now is the time to dream, out loud. What is your dream
version control system, if you could have it all? Why would it be that way?
Subversion 2.0, The Idea Phase, now open for business. :-)
[1] The Subversion Project: Building a Better CVS, Ben Collins-Sussman, Feb
2002 Linux Journal:
https://www.linuxjournal.com/article/4768
Re: Subversion's community health
Posted by Julian Foad <ju...@apache.org>.
Nathan Hartman wrote:
> All of the above -- being mature, reaching the stability phase, etc --
> is true of Subversion 1.x. It is _not_ true of "Subversion" without a
> 1.x after it.
> [...]
> Subversion 1.x is mature. Subversion 2.0 is now on the drawing board.
A very good point.
> [...]
> Prong 1: Everything you said about stability and availability for 1.x.
> People need to know that the Subversion they know, love, and rely upon
> will continue to take care of them.
>
> Prong 2: Open up a 2.0-dev branch even if there's nothing to put there
> yet. In any announcements about 1.x going stable make sure to mention
> that 2.0 is now open for business. People need to know that there is a
> future -- and they can help shape it!!!!!!
That's such a powerful idea, yes! The attitude that we don't have to
know what 2.0 will be, but can say "welcome!"... and see where it will lead.
Do you want to be the one to start a separate thread about this?
- Julian
Re: Subversion's community health
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Jun 18, 2019 at 7:00 AM Julian Foad <ju...@apache.org> wrote:
> Here is my suggestion.
>
>
> Primary goals:
>
> * Stability
>
<snip>
> * Availability
All of the above -- being mature, reaching the stability phase, etc --
is true of Subversion 1.x. It is _not_ true of "Subversion" without a
1.x after it.
Subversion 2.0 hasn't been born yet. Ironically, now is the time,
specifically because stability of 1.x means not introducing huge
groundbreaking features. But under no circumstances should such new
development be discouraged and turned away!! On the contrary, the
Subversion project should encourage it!
I believe there _will_ be new development in the future. Partly I
believe this because it's on my own to-do list, and I have some big
ideas that will _have_ to go in a 2.0 (even if 1.x didn't enter a
stability phase). Partly I believe it because Subversion offers some
great things that no other tool does. And partly because in my short
time on this earth, I've seen entirely too many occasions when
something was almost dead and came back stronger than ever, while
other things were flying high and mighty and then crashed and burned.
The name "Subversion" is actually the perfect name for this project.
It's a double entendre. While the technical idea is to control "sub-
versions" -- versions between versions -- the word "subversion" means
to transform an established social order. I'll say no more. :-)
Subversion 1.x is mature. Subversion 2.0 is now on the drawing board.
Let's make 1.x as stable and available as possible and let's encourage
discussion about 2.0 and all the great things ahead.
I recommend a two pronged approach.
Prong 1: Everything you said about stability and availability for 1.x.
People need to know that the Subversion they know, love, and rely upon
will continue to take care of them.
Prong 2: Open up a 2.0-dev branch even if there's nothing to put there
yet. In any announcements about 1.x going stable make sure to mention
that 2.0 is now open for business. People need to know that there is a
future -- and they can help shape it!!!!!!
Re: Subversion's community health
Posted by Julian Foad <ju...@apache.org>.
Here is my suggestion.
Primary goals:
* Stability
- because that's the stage in the project's life cycle
- if anyone wants to invest in development, that's fine too, but is
not what the current stewards of the project should be concentrating on
* Availability
- because stability for users (including admins) requires that they
can deploy it where they need it, and keep it up to date easily
- availability is currently poor -- see "Software Distribution" in
https://blog.foad.me.uk/2018/12/07/svn-whats-in-my-head/
For Stability:
* encourage commercial engagement for project maintenance
* encourage community maintenance by accepting minor feature
contributions and experimental initiatives
- don't let them compromise stability
* seek to remove or hide rough edges in existing features
- e.g. hide experimental features behind an opt-in config
For Availability:
* support availability of up-to-date install packages
- including today's cloud/container deployment platforms
* improve ease for downstream consumers using our releases
- see Mark's response about Subclipse
How?
* invite companies to contribute their existing build systems
- CollabNet, Assembla, RhodeCode, WANdisco
* find out what are the main desired target platforms
- provide a reference build system for each platform
- find and support maintainers for each platform
* change our release schedule to focus on maintenance releases
- reduce friction in version numbering, compatibility, multiple
release lines
* improve ease of producing new releases, especially bug fix releases
- automate the release steps (aim towards "one click")
- reduce friction in backports and releases policies (voting, etc.)
--
- Julian