On Apr 20, 2005, at 2:59 PM, Tim Hill wrote:
> Yes, some kind of switch would be good. OTOH, it is assumed by all
> that this is an svnadmin only command anyway.
Even as an svnadmin only command, reasonable care should be taken to
avoid data loss. Even if the default behavior is to actually destroy
the data, I think a --dry-run option is crucial. Since data is being
permanently destroyed, though, I think making the dry run default is a
reasonable idea. Even though those who have access to use svnadmin
should be more experienced users who understand the consequences of
what they're doing, they're still human. I can't imagine anyone being
upset that they have to type a few extra characters in order to
permanently destroy (potentially large) sections of their repository.
> As for backup, svnadmin dump can already do that.
Sort of. The svnadmin dump command only allows you to dump ranges of
revisions not specific files and all of their children (although
svndumpfilter will let you pare those down to certain paths, you still
can't have it follow copies and moves AFAIK). What I was suggesting
was a dump that included exactly the data that was pruned from the
repository. On the other hand, as I think about it more, it would be
hard to get the data from that dump back into the repository in exactly
the place where it was taken out, so that sort of dump might be of
limited use unless a means of loading it back in is also provided.
-Bill
>
> --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 Thu Apr 21 00:39:12 2005