Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <d31032d6-93ca-5020-efd5-f47e9450dcc5@apache.org>
References: <CAKRDqbB7m-nbTAS-kSHMyBpRCFoRZBfXcdF0BgC+8-z61Z=3jQ@mail.gmail.com>
 <de694027-4dc9-c8d7-f810-160b61ddbc56@apache.org> <54ea2280-ee9a-997e-4e57-b7e31dee5f1d@apache.org>
 <9f0070c3-8f6b-a59a-da42-76e21216251b@apache.org> <d31032d6-93ca-5020-efd5-f47e9450dcc5@apache.org>
From: Nathan Hartman <hartman.nathan@gmail.com>
Date: Thu, 27 Jul 2017 11:55:38 -0400
Message-ID: <CAJT2EHq_6L9Ur81Dft+X4i6gSe=yBCihAnXndW9g-1cjj5tk2Q@mail.gmail.com>
Subject: Re: Checkpointing mock-up option 3 (backed by a local repo)
To: Subversion Developers <dev@subversion.apache.org>
Content-Type: multipart/alternative; boundary="089e08e53d598c504705554e9852"
archived-at: Thu, 27 Jul 2017 15:55:50 -0000

--089e08e53d598c504705554e9852
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 27, 2017 at 7:56 AM, Julian Foad <julianfoad@apache.org> wrote:

> What can we learn from this mock-up? Here are some of my thoughts

(snip)

> If I checkpoint my changes, do I then want to see 'status' and 'diff'
>
against the original base or against the checkpoint? Both are useful.
>
(snip)

> Probably 'checkpoint init' should not be needed, and instead running
> 'checkpoint save' should initialize the checkpointing repo if not
> already done.
>
> Probably 'checkpoint finish|uninit' should not be needed, and instead
> should happen automatically when the user either commits or reverts the
> entire set of changes.
>

Some thoughts (probably too many)...

I agree that 'init' and 'finish' should happen automatically. Creation and
destruction of a hidden repository (or any data structure) is an
implementation detail that could change in the future and should not be
leaked. As you've already said, the 'init' should occur the first time a
checkpoint operation is done. As for when the 'finish' should occur, that
is a question I've been grappling with... I would say, probably not until
the results have been squashed and committed.

As far as what to name the commands, if the "checkpoint" command is changed
to "local" and the "save" subcommand is changed to "commit" then you get:

1. svn local commit
2. svn local revert
3. svn local rollback
4. svn local list|log
5. svn local squash
6. svn commit   <--- to the central repository

I think users will immediately start getting ideas about what this means.
Is that a good thing? It depends on what the goals are for checkpoints, how
checkpoints are intended to fit into the larger workflow, and strategy for
the future in general.

If checkpoints are intended to be merely a convenience with a limited
purpose, then I would call the command "checkpoint" and "checkpoint save"
to avoid confusion and make documentation, teaching, and learning easier.

If checkpoints are intended to have a much wider application, eventually
providing an answer to git's/DVCSs' ability to work offline and/or to do
personal work on projects to which one lacks commit privileges, then I
would use the shorter "local" (unless someone can think of a better,
shorter, and more descriptive name) and try to keep the sub-sub-commands as
close in semantics and function as possible to Subversion's original
command set. Even though the word "local" is technically a command, we
pretend it's more of a mode specifier that redirects what would normally be
server side operations to the local machine instead. Working on the local
machine essentially means working on a private branch. With that in mind,
to answer questions such as: whether a status or diff should be against the
original base or against the checkpoint, such questions should always be
answered consistently with how server side operations are carried out
today. Of course, if this feature is supposed to have such broad scope,
there is the (not insignificant) issue that users will have immediate
sky-high expectations that will take significant additional time and effort
to fulfill, so clearly this is not by any means an immediate goal; it's a
*possible* future direction, and if that kind of future appeals to enough
people, then the present work should try to be compatible with that future
by maintaining (to the extent possible) such a parallel between this new
"local branching" and the original server-side branching.

Some more thoughts...

(1) It will eventually be necessary to create a new "URL specifier" or some
sort of syntax to direct an operation into the checkpoint repo. This will
make it possible to diff between any permutation of working copy, central
repository, and local checkpoints, which will be crucial once users begin
to use checkpoints as local branches. I can see a use case where a 3-way
diff between all three is useful.

(2) Once checkpoints are working reliably, I suggest that "svn update"
should perform an automatic implicit "checkpoint save" (or whatever the
command is called) before attempting to fetch from the repository and merge
with the working copy. This will add a big safety net to what can be a
dreaded process. If an update turns ugly, you will be able to do that 3-way
diff I was just talking about.

(3) Eventually, squashing should be optional; that said, it's not feasible
to checkout a WC from a trunk that has lots of activity on it, work locally
for weeks, and then expect to replay the local commits onto the trunk
successfully. So I suggest this alternative: You can checkout a working
copy and make as many checkpoints as you want. When ready to commit, one of
the following happens:

    (a) you squash, update, and commit (which will turn into an infinite
loop if item #1 above is implemented and update creates a checkpoint...
hmmm... not good)

    (b) you can replay the commits to the server only if no other commits
have been made in the meantime (to trunk or whichever directory originates
the checkout)

    (c) you do not wish to squash but further commits have happened in the
originating directory on the server, so you have the third option: create a
new branch on the server and replay your commits onto that branch

I don't know if I'm making any sense here, but the reasoning is this: If
you're on the train to work and you make three checkpoints, you can use
option (a), squash, update, and commit. If you're working on a private
local branch and you make 300 checkpoints, then you can use option (c) to
"move" your checkpoints from the local machine to a new branch on the
server. This clears the checkpoints from your local machine and brings your
WC up to date with the HEAD of that new branch. Now, you can continue
working, make 300 more checkpoints, and (since no one else is working in
that new branch, (hopefully!!)), you can subsequently use option (b) to
continue replaying your checkpoints onto that branch.

There was one other thing... Oh yes. For "checkpoint save" or "local
commit" or whatever it ends up being called, I suggest ability to specify a
log message with -m or -F just like a normal commit. But for a checkpoint,
unlike a normal commit, I would make a log message optional; if not
provided, one is generated automatically.

I think that's about it for now. Hopefully these thoughts are helpful, not
overwhelming. ;-)

--089e08e53d598c504705554e9852
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jul 27, 2017 at 7:56 AM, Julian Foad <span dir=3D"=
ltr">&lt;<a href=3D"mailto:julianfoad@apache.org" target=3D"_blank">julianf=
oad@apache.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex">What can we learn from this mock-up? He=
re are some of my thoughts</blockquote><div>(snip)</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
If I checkpoint my changes, do I then want to see &#39;status&#39; and &#39=
;diff&#39;<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex">
against the original base or against the checkpoint? Both are useful.<br></=
blockquote><div>(snip)</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex">Probably &#39;checkpoint init&=
#39; should not be needed, and instead running<br>
&#39;checkpoint save&#39; should initialize the checkpointing repo if not<b=
r>
already done.<br>
<br>
Probably &#39;checkpoint finish|uninit&#39; should not be needed, and inste=
ad<br>
should happen automatically when the user either commits or reverts the<br>
entire set of changes.<br></blockquote><div><br></div><div><div>Some though=
ts (probably too many)...</div><div><br></div><div>I agree that &#39;init&#=
39; and &#39;finish&#39; should happen automatically. Creation and destruct=
ion of a hidden repository (or any data structure) is an implementation det=
ail that could change in the future and should not be leaked. As you&#39;ve=
 already said, the &#39;init&#39; should occur the first time a checkpoint =
operation is done. As for when the &#39;finish&#39; should occur, that is a=
 question I&#39;ve been grappling with... I would say, probably not until t=
he results have been squashed and committed.</div><div><br></div><div>As fa=
r as what to name the commands, if the &quot;checkpoint&quot; command is ch=
anged to &quot;local&quot; and the &quot;save&quot; subcommand is changed t=
o &quot;commit&quot; then you get:</div><div><br></div><div>1. svn local co=
mmit</div><div>2. svn local revert</div><div>3. svn local rollback</div><di=
v>4. svn local list|log</div><div>5. svn local squash</div><div>6. svn comm=
it =C2=A0 &lt;--- to the central repository</div><div><br></div><div>I thin=
k users will immediately start getting ideas about what this means. Is that=
 a good thing? It depends on what the goals are for checkpoints, how checkp=
oints are intended to fit into the larger workflow, and strategy for the fu=
ture in general.</div><div><br></div><div>If checkpoints are intended to be=
 merely a convenience with a limited purpose, then I would call the command=
 &quot;checkpoint&quot; and &quot;checkpoint save&quot; to avoid confusion =
and make documentation, teaching, and learning easier.</div><div><br></div>=
<div>If checkpoints are intended to have a much wider application, eventual=
ly providing an answer to git&#39;s/DVCSs&#39; ability to work offline and/=
or to do personal work on projects to which one lacks commit privileges, th=
en I would use the shorter &quot;local&quot; (unless someone can think of a=
 better, shorter, and more descriptive name) and try to keep the sub-sub-co=
mmands as close in semantics and function as possible to Subversion&#39;s o=
riginal command set. Even though the word &quot;local&quot; is technically =
a command, we pretend it&#39;s more of a mode specifier that redirects what=
 would normally be server side operations to the local machine instead. Wor=
king on the local machine essentially means working on a private branch. Wi=
th that in mind, to answer questions such as: whether a status or diff shou=
ld be against the original base or against the checkpoint, such questions s=
hould always be answered consistently with how server side operations are c=
arried out today. Of course, if this feature is supposed to have such broad=
 scope, there is the (not insignificant) issue that users will have immedia=
te sky-high expectations that will take significant additional time and eff=
ort to fulfill, so clearly this is not by any means an immediate goal; it&#=
39;s a *possible* future direction, and if that kind of future appeals to e=
nough people, then the present work should try to be compatible with that f=
uture by maintaining (to the extent possible) such a parallel between this =
new &quot;local branching&quot; and the original server-side branching.</di=
v><div><br></div><div>Some more thoughts...</div><div><br></div><div>(1) It=
 will eventually be necessary to create a new &quot;URL specifier&quot; or =
some sort of syntax to direct an operation into the checkpoint repo. This w=
ill make it possible to diff between any permutation of working copy, centr=
al repository, and local checkpoints, which will be crucial once users begi=
n to use checkpoints as local branches. I can see a use case where a 3-way =
diff between all three is useful.</div><div><br></div><div>(2) Once checkpo=
ints are working reliably, I suggest that &quot;svn update&quot; should per=
form an automatic implicit &quot;checkpoint save&quot; (or whatever the com=
mand is called) before attempting to fetch from the repository and merge wi=
th the working copy. This will add a big safety net to what can be a dreade=
d process. If an update turns ugly, you will be able to do that 3-way diff =
I was just talking about.</div><div><br></div><div>(3) Eventually, squashin=
g should be optional; that said, it&#39;s not feasible to checkout a WC fro=
m a trunk that has lots of activity on it, work locally for weeks, and then=
 expect to replay the local commits onto the trunk successfully. So I sugge=
st this alternative: You can checkout a working copy and make as many check=
points as you want. When ready to commit, one of the following happens:</di=
v><div><br></div><div>=C2=A0 =C2=A0 (a) you squash, update, and commit (whi=
ch will turn into an infinite loop if item #1 above is implemented and upda=
te creates a checkpoint... hmmm... not good)</div><div><br></div><div>=C2=
=A0 =C2=A0 (b) you can replay the commits to the server only if no other co=
mmits have been made in the meantime (to trunk or whichever directory origi=
nates the checkout)</div><div><br></div><div>=C2=A0 =C2=A0 (c) you do not w=
ish to squash but further commits have happened in the originating director=
y on the server, so you have the third option: create a new branch on the s=
erver and replay your commits onto that branch</div><div><br></div><div>I d=
on&#39;t know if I&#39;m making any sense here, but the reasoning is this: =
If you&#39;re on the train to work and you make three checkpoints, you can =
use option (a), squash, update, and commit. If you&#39;re working on a priv=
ate local branch and you make 300 checkpoints, then you can use option (c) =
to &quot;move&quot; your checkpoints from the local machine to a new branch=
 on the server. This clears the checkpoints from your local machine and bri=
ngs your WC up to date with the HEAD of that new branch. Now, you can conti=
nue working, make 300 more checkpoints, and (since no one else is working i=
n that new branch, (hopefully!!)), you can subsequently use option (b) to c=
ontinue replaying your checkpoints onto that branch.</div><div><br></div><d=
iv>There was one other thing... Oh yes. For &quot;checkpoint save&quot; or =
&quot;local commit&quot; or whatever it ends up being called, I suggest abi=
lity to specify a log message with -m or -F just like a normal commit. But =
for a checkpoint, unlike a normal commit, I would make a log message option=
al; if not provided, one is generated automatically.</div><div><br></div><d=
iv>I think that&#39;s about it for now. Hopefully these thoughts are helpfu=
l, not overwhelming. ;-)</div></div><div><br></div></div></div></div>

--089e08e53d598c504705554e9852--