Ryan Schmidt-23 wrote:
>
> On Jul 23, 2007, at 10:26, patrick wrote:
> "-r :N" and "-r M:" are not consistent with existing svn and svnadmin
> syntax, which is:
>
> [-r LOWER[:UPPER]]
>
> From "svnadmin help dump":
>
>> Dump revisions LOWER rev through UPPER rev. If no revisions are
>> given, dump all revision trees. If only LOWER is given, dump that
>> one revision tree.
>
> Using existing syntax, "-r :N" would be better expressed "-r 1:N" and
> "-r M:" would be "-r M:HEAD".
>
agreed
>
>> deleting a single revision makes it necessary to recalculate the
>> delta for
>> the version before or after (AFAIK DB and FSFS do deltas in opposite
>> direction)
>> deleting whole ranges makes it necessary to "sum up" these deltas.
>
> Remember that it's not necessarily (and not necessarily only) the
> immediately preceding or immediately subsequent revision that depends
> on a given revision. See skip-deltas:
>
> http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
>
>
true. in the FSFS example
0 <- 1 2 <- 3 4 <- 5 6 <- 7
0 <------ 2 4 <------ 6
0 <---------------- 4
0 <------------------------------------ 8 <- 9
if we want to delete the content of rev 4, we have to re-delta 5 and 6.
or more general if we have <2^n revisions of a file we have at max n-1
deltas to recalculate. correct?
btw: if you access revision (2^n)-1 you also have to sum up n deltas. so i
guess it is doable in reasonable time.
>
>
>> i can see the need for this function but IMO one could start with
>> the real
>> simple solution and have this added in a second iteration.
>
> And what is "the real simple solution"?
>
>
the removing of all revisions of a file. no deltas to recalculate.
>
> We must consider that FSFS repositories currently enjoy the property
> that revision files are immutable once created, and this property has
> been assumed by some backup scripts, probably both the official
> released scripts and some that have been home-grown. If we implement
> obliterate such that revision files are still immutable, then we have
> not truly implemented obliterate since the data is still there --
> even if we tell Subversion to ignore it. And if we instead implement
> obliterate such that old revision files get altered, then this has
> implications for backup scripts, and indeed for backup strategy.
>
i'm not sure if i understand correctly. probaly because we don't use
backupscripts but work with complete backups of the filesystem (assuming
that nobody works @03:00).
i don't think that altering old backups is a problem that has to be
addressed.
and for incremental/differential backup strategies i think it is no problem
with FSFS.
(excuse me for constantly only thinking FSFS)
but i admit that i have no clue how backups are done with DB.
>
>
> Consider a scenario in which a file is added to the trunk in r10,
> copied to branch1 in r20, copied to branch2 in r30, and modified in
> all three instances at various points in between and after. You now
> ask svnadmin to obliterate r15:35. What happens if you specify the
> file in trunk? Does it affect the other two files? What if you
> instead specify the file in branch1? What if you specify the one in
> branch2? I don't know the answers, I'm just saying svnadmin will need
> to know them before this can be implemented. Or, as a shortcut for an
> initial implementation, we could say that a file that has been copied
> cannot be obliterated.
>
my idea is that you can choose to not obliterate the file
or to obliterate it with all its ancestors.
probably it was these kind of questions which subconsciously formed my
"simplest version" scenario. wipe them away completely with all ancestors
and all successors.
i'm not so sure anymore at the moment if this complete wipe-out is realy the
80% scenario... any comments?
--- patrick
--
View this message in context: http://www.nabble.com/the-obliterate-discussion---why-dumpfiltering-is-no-valid-workaround-tf4116918.html#a11760146
Sent from the Subversion Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 24 12:11:59 2007