subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <>
Subject Re: [RFC] Shelving and Checkpointing
Date Tue, 11 Jul 2017 03:40:25 GMT
On Jul 10, 2017, at 8:59 AM, Julian Foad <> 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,

> References:
>   [1] Shelving-Checkpointing Dev doc. (J Foad)

View raw message