See, personally, I want to _force_ people to go through work to resolve
conflicts. If I give the people I develop with the option to quickly
and easily ignore the conflict markers and perform commits (reverting
changes that other people have made), I am positive that most of my
changes wouldn't get merged :). (I've seen what these people consider
"conflict resolution"... but they also commit with log messages like
"...", so this is definitely a non-cooperative environment, hehe).
I _do_ agree, though, with the premise, and second the comment that
being able to quickly repair working copies that were destroyed by
conflicts is a good thing. However, to me, that repair process should
actually lower the version number. If I do an update, and I get a lot
of conflicts, and I decide to just _rename files_ to get my program back
to a compiling state, then as far as version control is concerned I have
decided to make those the changes that will get used. What I'd like to
see is a svn undothat command (obviously that bikeshed is quite
dilapidated) that not only fixes a file but also reverts its version
number back to the version before it was updated. That way, there is no
hope of me committing it back to the server by accident, and the
metadata that "changes weren't even considered" isn't lost.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
-----Original Message-----
From: Vladimir Prus [mailto:ghost@cs.msu.su]
Sent: Wednesday, February 20, 2002 2:52 AM
To: dev@subversion.tigris.org
Subject: Re: conflicts, history, and the Principle Of Least Surprise
Karl Fogel wrote:
> I've just reviewed the recent thread about whether we should put
> conflict markers in files, or continue using .rej files as we have
> been, or do something else entirely.
> a) ...
> b) ...
Agree.
> c) We should behave as similarly to CVS as possible -- the Principle
> Of Least Surprise. This is really important, and was not given
> enough attention in the previous discussion imho. There's no
> point being gratuitously different if we can be an intuitive
> superset instead.
Your principle makes sense.
> The proposal is simply:
The reason I was suggesting that .rej file contain merged file with
conflict
markers was the following use case: you make update, suddenly get a
number of
conflicting files, and have to resolve all the conflicts just to make
the
program compile again. With your scheme, it is possible to just make
some
renames, and get the conflicting files in the state they had before.
And, as
the number of sudden conflicts is not likely to be large, it's quite
possible
to perform that renaming by hand. Therefore, I have no objections to
your
proposal. When implemented, it will considerably increase subversion's
usability -- I'm looking forward to it.
- Volodya
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006