On Fri, Jun 28, 2019 at 1:12 PM Thomas Singer <thomas.sin...@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!
