[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Obliterate questions

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Tue, 17 Nov 2009 00:28:27 +0000

Martin Furter wrote:
> On Mon, 16 Nov 2009, Daniel Shahaf wrote:
> > Philip Martin wrote on Mon, 16 Nov 2009 at 19:31 -0000:
> >> Martin Furter <mf_at_rola.ch> writes:
> >>> On Mon, 16 Nov 2009, Philip Martin wrote:
> >>>> How about replacing the text of a file, to obliterate a few
> >>>> characters, rather than obliterating the whole text.
> >>>
> >>> Say that revision was committed a few weeks ago and development continued.
> >>> So there were changes to that file in later revisions.
> >>>
> >>> How would you solve the conflicts when obliterating those later revisions?
> >>
> >> Conflicts? Obliterate operates on a given revision and obliterates
> >> whatever that revision contains.
> >
> > If you modify the text of an early revision, and a later revision is
> > stored as a delta against the early revision, wouldn't the representation
> > of the later revision possibly become corrupted?
> Or in fs_bdb where HEAD is fulltext (it's still that way right?) some
> earlier revisions could becom corrupted.

No, no, nothing will be corrupted. Part of the job of the software
functions that implement "obliterate a specified node-rev of file F"
will be to adjust any deltas, pointers, etc. in whatever way is needed
to make all other copies and revisions of F stay exactly as they were,
if the user doesn't want to obliterate all revisions and all copies of

> Additionally you just checkout HEAD and it still contains the parts which
> should have been obliterated.

No. Same reason as above.

> Or would I have to obliterate every single revision manually?

Only if you want every single revision of it to be obliterated. (And of
course the User Interface can give you an easy way to specify that.)

- Julian

Received on 2009-11-17 01:28:46 CET

This is an archived mail posted to the Subversion Dev mailing list.