> From: Tim Hill [mailto:tim@realmsys.com]
>
> Well, your pseudo-code is as much about implementation as any other
> post I've seen. "user-level abstraction" should only deal with
> externally visible effects. I also have some issues with the algorithm
> you present...
>
> What you end up with if you follow this procedure is rather odd. What
> happens when "revision" becomes > "torev"? In your pseudo-code, you
> will stop obliterating. But what does that mean? It means I have foo.c
> in revisions <= "fromrev", then it vanishes, and then ANOTHER foo.c
> appears by magic in revisions >= "torev". These two foo.c files will
> not be related in the repository, which seems to me to be very odd.
Yes it's odd, but then that's what the user asked for. The normal use
cases would be to obliterate 1:HEAD (remove completely), 1:R (discard
ancient history) or R:HEAD (undo mistakes).
Still, foo.c in revision fromrev-1 and foo.c in revision torev+1 _are_
related, by virtue of being on the same svn path. Certainly
svn diff -r(fromrev-1) foo.c
would work fine. I suppose. Well, it should.
The two foo.c's are not related in the sense that they use efficient
delta-storage. Actually executing my pseudocode literally would not
save space at all, it would explode the site of the repo because cheap
copies wouldn't be cheap anymore. A real implementation would have to
retain efficient delta-storage where possible, so please see my
pseudocode as no more than a description of what the virtual array of
filesystem trees would look like after an obliterate.
Another thing that's not taken into account is log history. Of course
the log history should be preserved, even if some of the entries refer
to revisions from which the path has been obliterated.
>
> I'm going to re-iterate what I've already said in this thread (and
> then shut-up). I think the real need here is for a PRUNE command. That
> is, given a file or folder and a rev number, remove that file in all
> revisions up to the HEAD revision, following all branches from the
> revision number onwards.
Sounds like that would be much simpler to implement, but I don't think
I would want to use it. Please rename the command to
TFdtxnBifu2nRGTLNZlj, so I don't execute it by mistake ;-).
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 14:47:08 2005