Shelving v1 (as in what I have done so far) supports text changes only.
== What next? ==
Several possible directions:
* Missing Support in Shelving (binary files, copies/moves, dirs)
* Integration with Changelists
* Supporting Cloud-based Code Review Systems
* Alternative Storage in WC metadata
=== Missing Support in Shelving ===
To move Shelving from a "starting point" to "fair usability" we will
need a v2 that supports some or all of:
binary files (and binary property values)
copies and moves
directory changes (mkdir, rmdir, properties)
See the "Straight Ahead" section below for details.
=== Checkpointing ===
Initial conversations on Checkpointing were headed in the direction of
what we might call a local branch, with full support for the versioning
operations that Subversion supports on a server branch. However this
would be a huge development.
The latest thinking on Checkpointing was that the quickest way to start
is a thin wrapper around shelving, emulating the manual approach of
saving a series of better and better patches:
'foo-1.patch' 'foo-2.patch' etc.
'svn checkpoint' increments the suffix number on the last used
(shelved) name and runs 'svn shelve --keep-local <NAME>-<NUMBER>'.
'svn checkpoint revert <NUMBER>' runs 'svn revert; svn unshelve
No support for commit-all-as-separate-commits, nor rebasing after 'svn
update', nor rolling back the base state to undo an update.
An initial version of this could be done in as little as ~2 weeks.
=== Integration with Changelists ===
The idea of a Change-Set is currently split 3 ways in Subversion:
commits, changelists, and now shelving. We should make this more
comprehensible by bringing these strands together, as discussed in the
section in Shelving-Checkpointing Dev:
=== Supporting Cloud-based Code Review Systems ===
Paul Hammant has noted how years ago Google got started building a
better code review system by scripting to send local changes from a
Perforce WC as patches to a review server. The Subversion SAS companies
like Assembla and RhodeCode now have code review and merge request
systems for Subversion. How can we improve support in this direction,
perhaps building on Shelving? Perhaps defining standards for such metadata?
=== Alternative Storage ===
An alternative is to store shelved changes in the same way as the WC
metadata already stores the WC working changes. Advantages:
* speed & space efficiency
* include the WC base version to enable 3-way merge.
The "missing support" in shelving (binary files, copies and moves,
directory changes, mergeinfo changes) will come along "for free" because
the WC already supports them.
Instead, the work is in extending the WC infrastructure. I believe the
effort needed to complete this is large and uncertain. A smaller effort
in this direction could yield benefits in the way of making the pristine
store more flexible, towards:
optional or compressed pristines (a separate wish-list feature)
using the pristine store also for the base of shelved changes
using the pristine store for shelved modified files,
-> much faster for large binary files
== The "Straight ahead" implementation of Missing Support in Shelving ==
The "Straight ahead" route is to Enhance "svn diff" and "svn patch"
feature-by-feature until they support all the required features. Here is
more detail on the steps required.
binary files (moderate effort, say ~4 weeks)
switch to 'git diff' mode
improve read/write speed of binary patches (for speed)
implement git-binary-diff delta mode (for space)
copies and moves (larger effort, more uncertainty)
mkdir/rmdir/dir-props (moderate effort, say ~4 weeks)
invent a syntax (probably like that for a symlink or empty file)
implement in 'diff'
implement in 'patch'
implement on/off control (e.g. diff --with-dir-changes)
mergeinfo changes (smaller effort, say ~1 weeks)
implement in 'patch': connect existing mergeinfo parser to make
Note: patch files are still inherently a sub-optimal design for large
binary files: not as fast as is possible with other designs.
Julian Foad wrote:
> == What next? == [...]
Re. checkpointing: I only gave a brief synopsis of what a really simple
v1 "checkpointing" might look like, not really enough to judge how well
it will work. I will spend up to a day or so thinking through the
details and write a specific design so we can see better how that idea
Similarly for every one of these developments, in fact.
Another thought: It is important to fix the deficiencies promptly, and
not to leave them as future wishes. In my experience using software that
nominally can do X but actually cannot do X in many real-life scenarios
is a terrible turn-off. Looking at these four current functional
deficiencies of "svn shelve" -- binary files, copies and moves,
directories, and mergeinfo -- while the mergeinfo one is clearly a bug
(we have all the required support code, it just needs connecting up), we
might reasonably want to label the others as "enhancements" from the POV
that we never supported them yet in patch files, but whatever we call
them they are all deficiencies that need enhancing to bring the feature
to the standard where a user can be confident that when they need to
shelve their work then they will actually be able to do so.
|Free forum by Nabble||Edit this page|