Maybe it would make sense to have svn prune do a dry run by default,
and just output the paths that would be deleted. Then, to actually
perform the deletion, you would need to specifically give an option.
It might also make sense to have an option that would dump the deleted
data, so that you could make a backup of everything that you were
deleting.
-Bill
On Apr 20, 2005, at 1:53 PM, Tim Hill wrote:
> Well, *any* form of permanent delete (obliterate, prune or otherwise)
> is going to have horror scenarios such as this one -- 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). 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. It's like a ref-count thing: once a
> branch is taken the pseudo-refcount for all prior revisions in that
> branches history are incremented (these don't exist of course in svn,
> I'm just talking about a logical construct). Logically, any obliterate
> command should never leave the tree with invalid refcounts, which is
> exactly what my *prune* (or whatever you want to call it) command
> guarantees.
>
> --Tim
>
>> For example: Suppose project B is created by borrowing the structure
>> from project A. That is, A is copied to B, and the files are
>> subsequently deleted from B, leaving only the directory structure.
>> Then works starts on project B. Years later, when making room for
>> project C, it is decided to obliterate that old project A that nobody
>> cares about anymore. As noone happens to be working on B at the time,
>> nobody notices its absense from the repository until after a full
>> backup cycle, and B is lost forever.
>>
>> - Anders
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 20 21:25:56 2005