Re: Checkpointing

[Branko Čibej]

On 30.06.2019 16:56, Nathan Hartman wrote:
> On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej  > 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: Subversion 2.0

[Nathan Hartman]

On Sun, Jun 30, 2019 at 4:47 AM Greg Stein  wrote:

> On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman 
> 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: Checkpointing

[Thomas Singer]

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

[Nathan Hartman]

On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej  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

[Nathan Hartman]

On Fri, Jun 28, 2019 at 1:12 PM Thomas Singer 
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: Subversion 2.0

[Greg Stein]

On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman 
wrote:

> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej  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