Re: How to reject svn changes?

On Sun, Mar 16, 2008 at 8:35 AM, Lasse Vågsæther Karlsen
<lasse_at_vkarlsen.no> wrote:
> While I sympathize with the problem I do believe that the problem is not
> something that a source control system should do much to solve.

I am a proponent of getting something done improving the obliterate
feature urgently - however I really do have to concur here that this
isn't a great use of obliterate.

Backing out the changes with a reverse merge is easy and, in terms of
UI simplicity, unlikely to be improved in obliterate.

The cost to the system in terms of space is trivial (only the size of
the change, ignoring skip-deltas). It would seem that, at best, a
case could be made for avoiding a noisy revision history but even then
I'm hard pushed to see this as a good use.

Trying to use obliterate in this fashion outright demands that either
all users re-check out or that the system do a considerable amount of
complex but low-value work to communicate how history has changed to
clients that need to be informed (such as mirrors or clients with
working copies at the removed revision).

> However, at some you're going to have to trust your developers, and if you
> can't do that, I'm sorry to say this, but there isn't much a source control
> system will do to help that problem.

Developers make mistakes, sure, that's expected - it happens - seeing
that it's happened in revision history isn't going to hurt anyone.
Obliterate needs to deal with these specific cases when there is no
way to continue with the repo in its current state - surely this isn't
one of those cases when a reverse merge gets you to where you need to
be with minimal cost.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org