On Feb 2, 2005, at 9:58 AM, Roel Harbers wrote:
>
> Just for my understanding of things:
> 1 - I change a huge file into a tiny one (deleting the contents of the
> file, but not the file itself)
> 2 - I commit that change (rev 100)
> 3 - I want to undo that change, so I do svn merge 100:99
> 4 - I commit that change (rev 101)
>
> Now, the (huge) data of that file is in the repository *twice*, right?
> Once for the initial checkin, and once for the "undo" (because there
> is no merge tracking, so the commit in step 4 cannot distinguish
> between step 3 and the alternative: manually replacing the tiny file
> with the old huge file)
Well, the repository stores successive revisions of files as compressed
binary diffs. If you're using BDB, then r101 of the file is the "full"
file. r100 of the file is stored as a compressed diff against r101 (so
it's basically the "full" file, compressed, but in reverse), and r99 of
the file is a compressed diff against r100 (again, the "full" file,
compressed the other direction).
So really, the file's text is in the repository three times now, though
two of them are compressed.
This is pretty extreme edge-case, by the way. Most "undo" commits
aren't changing gigantic files.
>
> Also, it seems that after this "undo", the blame info is gone: all
> lines were changed during the last commit.
>
Correct. But that's part of history. You cannot selectively ignore
chunks of history: if every line was deleted at some point, that
information is permanent.
If you want to see the blame information, run it on r99 of the file, so
blame can trace backwards from there.
> Is this a correct representation of things? Is there a better way to
> undo?
>
The simple fact is that the repository never loses information, ever.
This is considered a feature. :-)
The only way to force information loss is to dump/filter/re-load the
repository, essentially breaking every existing working copy. Chapter
5 discusses this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 2 17:32:24 2005