On 17.03.2012 14:06, Stephen Butler wrote:
> On Mar 17, 2012, at 13:43 , Branko Čibej wrote:
>
>> On 17.03.2012 11:25, Stephen Butler wrote:
>>>>> Somewhat off-topic, but "svn update" has the serious problem that it's
>>>>> impossible to revert to the state before the update if one had local
>>>>> changes. Most of these "pick sane defaults" kinds of discussions would
>>>>> become moot if one could have some kind of client-side snapshot that let
>>>>> revert be something more than just an all-or-nothing proposition.
>>>> That's a great suggestion, I agree that would be a very good
>>>> improvement. It would allow to have more control, but only if you need
>>>> it (in case you noticed after the fact that something went wrong, and
>>>> you can back up step by step).
>>> There was talk about a "local commit" feature a while back. I bet most
>>> of the user who like that feature would actually be satisfied by an
>>> 'svn undo-update' command.
>> Are you assuming that "undo update" would be easier to do than "local
>> commit" (I prefer the term "savepoint", but teal.bikeshed.com)? :)
> I haven't thought about internal design or implementation yet, just taking
> a user's point of view. Update works fine almost every time. Once in a while
> I take a wrong turn in resolving conflicts, and would like to reset the working
> copy to where it was before the update (with local changes and probably
> mixed revs). It'd be a bummer if I had to remember to run 'svn savepoint'
> first.
Oh, certainly. If we go down this road, then "update" should imply
"savepoint" first.
But the implementation would be the same for both. If you want to revert
to a previous state of the working copy, including local modifications,
then you need a mechanism to store the working copy state, and to revert
to said state. Once you have that, It should be trivial to manage a
stack of states. "svn update" would push a state to that stack, but that
wouldn't stop anyone from creating an "svn save" command.
I see two ways to implement "svn commit" in this case. The simpler one
is to have commit work as it does now, i.e., impose the current working
copy state onto the repository, regardless of possible savepoints. The
more complex way (which, heh, I'd prefer) would have commit record all
intermediate states in the repository, too -- on an automatic
micro-branch. The only trouble is that, in order to do such a thing, one
would need first-class branches -- which Subversion doesn't have.
-- Brane
Received on 2012-03-17 14:15:11 CET