On Apr 18, 2005, at 5:09 PM, Tim Hill wrote:
>> Did anyone read my ideas earlier in the thread about a possible
>> implementation?
>> The file could appear as a copy with modifications from an earlier
>> rev that is 0 bytes in size. That is, the file in the trunk was
>> obliterated, but there could be a placeholder file left there to keep
>> other bits of the repo structure sane, the branch copy can be
>> reworked to show the history as coming from the placeholder file but
>> having the entire contents added.
>> I'm not sure if that makes sense, but it seems like a good starting
>> point for further discussion.
>
> How would the 0 byte idea work for multiple branches? At the first
> branch (working backwards) I might be able to do this, but then I have
> to propogate *that* 0 byte file backwards to the previous branch, and
> inject a fixed-up add at the branch point for *that* branch.
No. My proposal is designed to preserve the global revision numbers in
order to have minimal impact on everything else. You would only inject
a fixed-up add where there is a real add. Everywhere else you fix-up
the diffs so that the history of the file is essentially blank.
> So the end result is I end up with a whole bunch of 0 byte files all
> over the place with curious histories.
The histories aren't exactly "curious" :) They track when the original
file was changed and what paths it was at. The whole reason for the 0
byte files is that I was specifically attempting to preserve the
histories as they were, but with 'obliterated' contents. Just so the
paths that other things might have depended on (in terms of branches
AND rev numbers) all still exist as they were. The big thing is
preserving all the rev numbers, which seems to be the part that could
mess up all sorts of other things in ways that wouldn't be obvious.
> Frankly, that doesn't sound much like "obliterate" to me :)
I know what you mean, it isn't perfect. It is obliterate in the sense
that the file contents are gone - so sensitive data and large files
committed by mistake are eliminated. It was this compromise that I
thought might specifically allow for a much easier implementation
because the revision tree still has the same shape.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 19 01:52:11 2005