You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels Janosch Hofmeyr <ne...@elego.de> on 2009/06/20 23:20:18 UTC
svn obliterate? svn overwrite!
Hi all,
just now I had a discussion on #svn where a user o2T7 asked about undo. We
drifted into "svn obliterate", and o2T7 compared the workings of svn to
human memory. He said:
<o2T7> well, what real minds do is "imagine" or "fill with convenient data"
what they would like to be there ;)
So, instead of removing a revision that contains sensitive data, might it be
easier to just *overwrite* those sections that company X doesn't want to be
sitting in their repos?
It's still checksum business. But it's a smaller set of problems than with
"svn obliterate". Maybe some brilliant mind could find out how to overwrite
without changing the checksum result.....
Any case. I like the approach :)
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363846
Re: svn obliterate? svn overwrite!
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Bert Huijben wrote:
>> -----Original Message-----
>> From: Neels Janosch Hofmeyr [mailto:neels@elego.de]
>> Sent: zondag 21 juni 2009 1:20
>> To: dev@subversion.tigris.org
>> Subject: svn obliterate? svn overwrite!
>>
>> Hi all,
>>
>> just now I had a discussion on #svn where a user o2T7 asked about undo.
>> We
>> drifted into "svn obliterate", and o2T7 compared the workings of svn to
>> human memory. He said:
>>
>> <o2T7> well, what real minds do is "imagine" or "fill with convenient
>> data"
>> what they would like to be there ;)
>>
>> So, instead of removing a revision that contains sensitive data, might
>> it be
>> easier to just *overwrite* those sections that company X doesn't want
>> to be
>> sitting in their repos?
>>
>> It's still checksum business. But it's a smaller set of problems than
>> with
>> "svn obliterate". Maybe some brilliant mind could find out how to
>> overwrite
>> without changing the checksum result.....
>>
>> Any case. I like the approach :)
>
> On every update (switch, etc.) you receive binary diffs from the repository
> that assume your local base-version exactly matches the file on the server
> (or the binary diff talks nonsense).
>
> With this change you would void that assumption.. (just assume updating from
> or to the to be obliterated revision) and you would trick the validation
> rules too.
>
> So.. the result would be that all your existing working copies might be
> broken, but you will never know if they are...
>
> (And if you assume that there are no working copies using this version..
> then you could just as well change the checksum and/or use svndumpfilter (or
> manual patching of the dumpfile))
>
>
> And this doesn't even look at the fs-layer dependencies on old versions.
> (Versions of nodes can be stored as a binary diff against older and newer
> versions of the file)..
>
>
> Bert
Heh, no doubt there are lots of difficulties... I just fancied the thought
of scrambling instead of cutting. But I see that it doesn't make it any
easier in practice.
I, personally, don't care much for either. Just thinking aloud...
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363859
RE: svn obliterate? svn overwrite!
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Neels Janosch Hofmeyr [mailto:neels@elego.de]
> Sent: zondag 21 juni 2009 1:20
> To: dev@subversion.tigris.org
> Subject: svn obliterate? svn overwrite!
>
> Hi all,
>
> just now I had a discussion on #svn where a user o2T7 asked about undo.
> We
> drifted into "svn obliterate", and o2T7 compared the workings of svn to
> human memory. He said:
>
> <o2T7> well, what real minds do is "imagine" or "fill with convenient
> data"
> what they would like to be there ;)
>
> So, instead of removing a revision that contains sensitive data, might
> it be
> easier to just *overwrite* those sections that company X doesn't want
> to be
> sitting in their repos?
>
> It's still checksum business. But it's a smaller set of problems than
> with
> "svn obliterate". Maybe some brilliant mind could find out how to
> overwrite
> without changing the checksum result.....
>
> Any case. I like the approach :)
On every update (switch, etc.) you receive binary diffs from the repository
that assume your local base-version exactly matches the file on the server
(or the binary diff talks nonsense).
With this change you would void that assumption.. (just assume updating from
or to the to be obliterated revision) and you would trick the validation
rules too.
So.. the result would be that all your existing working copies might be
broken, but you will never know if they are...
(And if you assume that there are no working copies using this version..
then you could just as well change the checksum and/or use svndumpfilter (or
manual patching of the dumpfile))
And this doesn't even look at the fs-layer dependencies on old versions.
(Versions of nodes can be stored as a binary diff against older and newer
versions of the file)..
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363852