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
Received on 2017-11-01 11:36:13 CET