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
Received on Wed Apr 20 20:56:09 2005