On Tue, Jul 11, 2017 at 4:53 AM, Julian Foad <julianfoad_at_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
Received on 2017-07-12 00:15:50 CEST