Re: Checkpointing

[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: Checkpointing

[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

[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

[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

[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

[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

[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

[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!