On Jul 10, 2017, at 8:59 AM, Julian Foad <jul...@assembla.com> wrote: > > Dear Subversion Developers, > > I am delighted to announce that I am working with Assembla to develop > shelving and checkpointing functionality in Subversion. These have > been on the wish list for many years, and are becoming ever more in > demand since the popularity of git is making more users appreciate the > benefits of local operations.
Hi all, I just wanted to chime in and say that I'm very happy to hear that these local features are planned for Subversion. After ten years of using Subversion, I can say that it has been a joy to use from day one, owing in large part to its simplicity and reliability. It occurred to me recently that in the distant past Subversion's purpose was to be a better CVS, that that goal has been achieved long ago, and that perhaps it's time for a Subversion 2.0, which could take it to the next level. I don't know much about future plans, such as what FSX is intended to achieve, but it occurred to me that perhaps Subversion could gain the ability to do local commits, which could be an optional step before doing the real commit back to the repository. As I thought about that, I realized that it might not have to require too much new machinery to achieve that. I had this idea: When you checkout a working copy, Subversion creates the hidden .svn directory which contains the pristine copies among other things. What if, instead of just a pristine copy, it actually created a private local repository. Revision 1 of this repository would be the pristine copy. The user need not know that anything has changed and can continue working as before, committing back to the server. But, if you type some other command instead of commit, or maybe prepend the word "local" or something, the commit would go into the local repository rather than the remote one. Now this makes it possible to do locally anything you could do remotely such as creating multiple local feature branches. It also means that when you do an update, there could be an implied local commit first, which allows you to undo an update which perhaps messed something up. Shelving, stashing, etc., all become local operations against this local souped up pristine copy replacement. Since you're only checking out one revision just as before, as opposed to cloning a whole repository, this idea comes with some big advantages that you don't get with git or hg, such as that you need not clone an entire gigantic repository. This is one of the big reasons that those systems are not a good choice for housing lots of big files that change infrequently, as every user would have to clone potentially gigabytes of data they're not interested in. In other words a svn checkout still does what it always did before, except that you have the option to work locally if you want to. I didn't mention any of this before because: (1) there are obviously a lot of holes in this idea, such as, what happens to this private local repo when you do a svn switch? Or the pesky issue of how to add such a major new feature without inheriting a ton of obscure commands a la git? And (2) although I am a developer and very fond of Subversion, I cannot take this upon myself because of other obligations now and in the foreseeable future. So I felt it would be rude to dump a crazy idea like this on everyone else. Julian's post prompted me to break my silence, not knowing if what I've suggested is remotely realistic. I realize that this suggests a major backwards-incompatible change to the working copy format and indeed the entire client side. But this was a request for comment. :-) Hopefully someone finds my input valuable. Kind regards, Nathan > References: > [1] Shelving-Checkpointing Dev doc. (J Foad) > https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#
