Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Server-side SavePoints [was: Subversion Design Contribution Question]
To: "Daniel J. Lacks, PhD" <DannyL9143@aol.com>
References: <9251FD4B-AA01-48C0-A037-2ADFB45FD9C8@aol.com>
From: Julian Foad <julianfoad@apache.org>
Cc: dev@subversion.apache.org
Message-ID: <f1f1d437-56cb-1d2e-a2e3-46759e835c6b@apache.org>
Date: Wed, 1 Nov 2017 10:36:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9251FD4B-AA01-48C0-A037-2ADFB45FD9C8@aol.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
archived-at: Wed, 01 Nov 2017 10:36:14 -0000

Hello Daniel. Thanks for your interest in discussing this. Emailing this 
list is indeed the right way to do so.

Having answered that meta question, I am changing the email Subject to 
reflect the substantive topic.

Daniel J. Lacks, PhD wrote:
> I am interested in the design topic for SavePoints. I was wondering
 > if anyone considered server-side stashes instead of client-side?

I am currently working on Shelving and Checkpointing, features which are 
more or less what the SavePoints page envisions (although not 
necessarily the implementation it describes). References:

https://wiki.apache.org/subversion/SavePoints
https://issues.apache.org/jira/browse/SVN-3625 "Commit shelving"
https://issues.apache.org/jira/browse/SVN-3626 "Commit checkpointing"

These are deliberately client-side features for the main reasons of 
speed and offline usability. Speed is critical: one of the main use 
cases is to be able to switch *quickly* between small tasks, and this 
has to be useful for people using a relatively slow WAN connection.

Have we thought of the server-side possibility? Of course. (See for 
example the 2nd/3rd comments in those issues.) But Subversion already 
supports saving work to a server-side branch, so we need to ask, what do 
you need for your use case, beyond the present ability to use branches? 
So let's explore further.

> The stash would work similar to a commit
> except it would check-in code perhaps in a hidden or protected branch
> within the svn:stash workspace.

Making namespaces of branches that are 'hidden' or 'protected' is 
something that can potentially be done with server authz rules, but is 
this important for you? Why? If you just designate 
'^[/project]/branches/user/USERNAME/*' as the place for USERNAME's 
branches, with no special protection, does that work?

> This would allow developers to not only
> swap workspaces, but to swap them across multiple physical machines or
> VMs. It is also possible to share those changes with others as well, for
> example the basic commands to show SavePoints may only show your save
> points, but perhaps there can be an optional argument to show anyone’s
> SavePoints either on your branch or any branch. I imagine that swapping
> to a SavePoint would first work like a switch command to get you to the
> same point you were (optionally), then a pseudo-merge command to grab
> the changes and copy them into your local directory. It seems like such
> a capability may be built reusing some existing functionality.

It certainly can be done by (re)using existing functionality :-)

# save my local changes
svn copy -m "save" . ^/branches/save/$USER/foo

# revert my local changes, now they're saved as 'foo'
svn revert -R .

# show my save points
svn list ^/branches/save/$USER

# show everyone's save points
svn list ^/branches/save -R

# apply save point 'foo' to my WC
svn merge ^/branches/save/$USER/foo

There's not even a need for separate 'switch' and 'pseudo-merge' steps, 
if we assume my WC is already on the same branch (e.g. trunk) from which 
the save-point branch 'foo' was created.

Seriously, though, I can say some things.

I am sure you wish for a user-friendly command-line interface to access 
this scheme, such as "svn shelve --list" (which would translate to "svn 
list ^[/project]/branches/save/$USER" if that is the underlying storage 
scheme).

Subversion is intended to be a system which has a core part with 
libraries and a simple command-line interface, that is then extended 
upwards with third-party interfaces such as TortoiseSVN, Cornerstone, 
Visual Studio / IntelliJ / NetBeans IDE integrations, and others.

Maybe this kind of use of branches for 'shelving' is more the job of a 
higher layer of software built on top of Subversion core, or an 
alternative command-line client. Not all features like this should be 
built in to the core. One of Subversion's strengths is the simplicity of 
its command set. Of course this cuts both ways: if this functionality is 
commonly wanted then there should be an easier way to access it.

One difficulty here is we (this group of developers subscribed to dev@) 
don't really get involved much in designing Subversion features outside 
the part that we produce ourselves. Maybe we could change this. If we 
draw a diagram showing the core and third-party Subversion software, 
showing what is in the core and what sort of features we expect the 
third-party software to provide, that just might incite those 
third-party developers to go and build those features.

Another angle, touched on by Paul Hammant in his reply, is portability 
of change-sets. Let's say we implement client-side shelving. The next 
logical request is certainly going to be a way to transfer those shelved 
changes easily to a branch from where they can be moved to another 
client machine, shared, backed up, etc. And, in his interesting case, 
transferred to a code review system which is separate from the 
Subversion server.

So "standardized server-side handling of such things", as he puts it. 
What can we do in this direction?

One thing we can do is make a Subversion 'patch' format that is a 
complete serialized representation of any potential Subversion commit. 
The 'svnadmin dump' format is a serialized representation of an actual 
commit, based on a specific previous revision number. For a 'patch' 
representing a potential commit, we don't know the eventual base 
revision yet, and so we need the sort of flexibility in applying it that 
a 'context diff' gives. We need to meld the 'context diff' idea (which 
originally is only defined for plain text) with the ability to specify 
all possible Subversion operations including copies and moves, 
directories, and properties.

Another thing we can do is look at what sort of commands and 
infrastructure will be needed to refer to these change-sets and send and 
receive them. For example, 'shelving' should have 'import' and 'export' 
commands to bring change-sets into and out of the 'shelved' space, and 
also there should be ways to import a change-set directly to a new 
branch and export one from a branch. I say this because if you build a 
system where there are several concepts like 'shelved changes' and 
'changelists' and 'commits' but for each concept there is only exactly 
one thing you can do with it (for a shelved change: you can unshelve 
into the wc, only) that system becomes limited and clumsy. Some things 
you can do require two or three steps to do, when logically they should 
only require one step.

So, yes, lots of interest. What do you (all) think?

- Julian