On Nov 2, 2017, at 9:49 PM, Daniel J. Lacks, PhD <dannyl9...@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
