On Tue, Jul 11, 2017 at 4:53 AM, Julian Foad <julianf...@apache.org> wrote:
> Nathan Hartman wrote: > >> [...] 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. [...] >> > > That is exactly what I was thinking about when I wrote "Option 3... > Checkpoints are commits in a local repository embedded in the WC" towards > the end of that document. My feeling is that both the amount of effort > required just to get that far, and the explosion of further possibilities > it would open up, make it too heavy-weight for my current project, but I > would definitely like to explore that possibility further. The explosion of possibilities, to borrow your words, is IMO a disadvantage of Option 3. I'm saying this despite having suggested this same idea. I'd like to emphasize that I don't advocate turning Subversion into a DVCS. Proponents of DVCSs seem to think that Subversion's centralized nature is a disadvantage. I think the exact opposite. With centralized, you get Single Source of Truth, a system that is easy to learn, easy to teach, programmers and non programmers can use it successfully. I like that history is immutable, never rewritten, because I think the primary responsibility is to never lose information. You only have two places to know about: the repository and your working copy. What I do like is the idea of remaining centralized while having some local capabilities. The stashing / checkpointing wishlist items are valid. I mentioned the ability to roll back a svn update if something unexpected happens (by doing an implied local commit of your current state as the first step of svn update). Local feature branches could be useful for one-off experiments, short-lived work done by one person, etc. In any case, these features should all be optional. They'd be there if you want them, but you never have to know about them if you're not interested. In any event, I wouldn't go full blown DVCS where the concept of repository vs. working copy goes away. I wouldn't turn a checkout into a full clone, or a working copy into a repository. Other than the addition of new features in the client, all else would remain the same. Why put a hidden repository in the working copy, then? The reason is that while the client could use a different "lighter weight" method to manage various versions of its working copy, that would reinvent the wheel. You'd end up with a second incompatible version control system within Subversion. If I understand correctly, the client already has server code in it, because when you use the file:// URL scheme, the client is the server. So why reinvent a new version control system within Subversion when it already has everything it needs? But here's the key: The difference between a normal repository and the hidden one in the working copy is that the latter is a hidden implementation detail, not something the user can access or control. For example you can't checkout a working copy of it. Everything that concerns that hidden repo, its creation, the directory and file layout within it... all of that is controlled by Subversion itself. It's more of an internal client-side filing system than an actual repository, although it uses a repository as the underlying implementation. The user gets some new local features, but not the dreaded "explosion of possibilities." Kind regards, Nathan
