You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nathan Hartman <ha...@gmail.com> on 2019/06/21 11:12:45 UTC
Subversion 2.0
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 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/
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 "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