From: Tim Hill [mailto:tim@realmsys.com]
>
> Well, *any* form of permanent delete (obliterate, prune or
> otherwise) is going to have horror scenarios such as this one --
I do think prune is a tad more insidious than the alternatives.
> avoiding these is the whole point of a system that doesn't support
> "permanent" changes, isn't it? :-)
>
> And I'm not sure I agree with this scenario. Putting aside the "if
> misued, it can do bad things" for a moment, in your scanario, the
> correct thing to do with project A is to prune it just *after* the
> branch to project B (sort of --stop-on-copy).
Prune with --stop-on-copy would suffer the same implementation
difficulties as my version of obliterate, and the same issues with
dealing with branches and tags.
A functional difference is that my obliterate will delete anything
that later appears on an removed path. Say a branch that is promoted
to trunk by deleting trunk then copying branch to trunk. Also my
obliterate will support the 1:R use case of deleting old history of a
live project without affecting recent revisions. I especially like
being able to ditch old trunk revisions while retaining all the tags.
>This deletes the dead
> "A" project but leaves "B" with it's full history. And this, of
> course, is also logically correct -- once the "B" branch is created,
> the implication is that the earlier history of "A" is actually a
> COMBINED history of both "A" and "B", and certainly should not be
> deleted just because "A" is dead.
So pruning the A project was the wrong thing to do? The problem is
that every step on the path to doom seemed quite reasonable. How
would you know there is an A/B relationship to be delt with in the
first place? Sure, you *might* notice the B project in a dry-run
output, between the myriad of A project tags and branches, but then
the old geezer you consulted to ask what was worth keeping, did say
that A had a bunch of spun-off customer-adaptation projects, none of
which were worth keeping. So you press on, knowing the alternative is
to use the --stop-on-copy switch and spend the rest of the day pruning
all those other copies that you really do want to ditch, one by one.
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 21 13:58:50 2005