subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <hartman.nat...@gmail.com>
Subject Re: Server-side SavePoints [was: Subversion Design Contribution Question]
Date Fri, 03 Nov 2017 06:55:18 GMT
On Nov 2, 2017, at 9:49 PM, Daniel J. Lacks, PhD <DannyL9143@aol.com> wrote:
> 
> Hi Julian,
> 
> I appreciate your insight into thinking about the problem and your knowledge of SVN is
evident.  You are correct about my intentions, while it is possible for the user to reuse
commands (or scripts) to do such an operation (local or remote), I was hoping that reuse made
the SVN software development of a capability easier to implement as an SVN command.  I am
not against client-side shelving or checkpoints, but I think that a server-side capability
is also useful.  I am in favor of both client-side AND server-side stashing concepts, not
necessarily only doing one or the other.  

Hi all,

I've been busy and haven't chimed in for some time about SavePoints (which were still called
check points when I last participated in the discussion). First I'd like to say that I like
the name SavePoints and agree with the rationale stated at the wiki, particularly that with
this name, the command can be shortened to sp and that it will likely make more sense to non-native
speakers of English than check points.

More to the point of this thread, I think the idea of client- and server-side SavePoints does
make sense for the reasons stated previously. I like very much the idea that server side SavePoints
could provide some of the underlying machinery for code review. I'd like to add the following
to the list of potential use cases: Given the core svn library / third party value-added nature
of Subversion, I can imagine a feature in, say, TortoiseSVN, where SavePoints are taken locally
immediately, and when a line of communication to the server exists (which could be at the
same time or at some later time) the SavePoints would be automatically transferred (copied
/ synched) to the server. That is, SavePoints are local and provide the ability to "work offline"
for extended periods, but transparently become "online" at the next opportunity when communication
permits. One could say that local SavePoints are transparently backed up to the server.

I think this would give users some very good benefits. For one, it would reduce or eliminate
the need to remember to transfer SavePoints to the server manually. It would provide a safety
net in case of loss of a WC, as occurs when a virtual machine goes haywire and the user deletes
it with all its content and replaces it with a fresh VM and new checkout. (This has happened
to me enough times!) It also answers a concern I have with anything that is local as opposed
to server-side: my working copies are all in a RAM-disk! It speeds up builds and searches
considerably, reduces wear on my laptop's flash storage, and enforces in my mind the idea
that the working copy is very temporary and can be lost or damaged at any time--which encourages
small frequent commits. So with the addition of local SavePoints, the concern is that if I'm
in a RAM-based working copy, the SavePoints are no more durable than the working copy itself.
But if the SavePoints are synchronized to the server, either manually or automatically / transparently,
then I can continue to work happily in my RAM-disk while reaping the benefits of SavePoints
and the safety of centralized version control.

Hopefully these thoughts are beneficial to the community.

Kind regards,
Nathan 


Mime
View raw message