Yes, some kind of switch would be good. OTOH, it is assumed by all that
this is an svnadmin only command anyway. As for backup, svnadmin dump
can already do that.
--Tim
William Nagel wrote:
> 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 22:02:28 2005