> -----Original Message-----
> From: patrick [mailto:Patrick.Wyss@mobilesolutions.ch]
> Sent: Tuesday, July 24, 2007 6:13 AM
> To: users@subversion.tigris.org
> Subject: Re: svnadmin obliterate features (was: RE: the
> obliterate discussion - why dumpfiltering is no validworkaround)
>
>
> . . . .
> >
> > 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.
>
It would seem then that following an obliterate operation, one would have to
invalidate any existing incremental backups and maybe all your existing
backups too. After all, they depend on a state of the repository that no
longer exists. If an admin uses a complex backup strategy, he then has to
start from scratch with a complete backup and restart the backup scheme.
If we didn't do that, then we'd have a situation where, in order to restore,
one would have to apply some incremental backups up to the point of the
obliterate operation, then repeat the obliterate, and then continue with
restoring backups (because the structure of the repository is now
different). Thinking about "obliteration tracking" makes merge tracking
seem trivial.
>
> >
> >
> > 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.
> >
>
Does it make sense to limit obliterate to just the branch you specify? If
the file has been copied to another branch, then any cheap copy needs to be
made expensive there, or you need to do obliterate operations in the other
branches too.
I don't know if this makes the task easier/harder/impossible. My point is
that even if obliterate did not follow all the file history, but simply
obliterated and updated the repository in specific branches, it would be
very helpful.
If the operation created a new revision of the repository, so that I could
log the fact that file(s) had been obliterated, that would be good.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 24 15:37:12 2007