On Sun, 2009-12-27, David Glasser wrote:
> That's great to hear!
>
> What's the effect on WCs? Do WCs with the bad rev get "fixed" on
> update? Do WCs that never had the bad rev skip over it fine?
Hi Dave.
At the moment, WCs with the bad rev get broken in some way that I have
yet to investigate. (See "There is also a bug ..." below.) It may well
be the repository that is broken rather than the WC, or it may be both.
WCs that never had the bad rev will, I hope, skip over it fine, but I
haven't tested this yet. At present, the oblit is implemented only on
the latest rev of a node (it doesn't fix up back-references from future
versions of the node yet), so the only way to trigger this behaviour is
to commit more revisions after doing the obliterate. Again, I have yet
to test this.
- Julian
> --dave
>
> On Tue, Dec 22, 2009 at 11:21 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > Hi, Obliterate fans.
> >
> > As of r893267, if you compile with "-DSVN_WITH_EXPERIMENTAL_OBLITERATE",
> > you get an "svn obliterate" subcommand which is capable of obliterating
> > the latest revision of a file. In my tests so far, it seems to work in
> > very limited circumstances.
> >
> > You can run the "obliterate_tests.py" which creates a test repository
> > and then tries to do five obliterates. The first obliterate on a node
> > path "f-mod/F" works, and then it fails on the next one "f-add/F". If
> > you go to the working copy and try examining the history, can you find
> > any errors?
> >
> >
> > May not work:
> >
> > ? Node is a directory
> > - I think I implemented it, but not yet tested so probably not yet
> > working.
> >
> >
> > Does not work:
> >
> > x Node was added in that revision
> > - A bug which I have not traced yet: "No record in 'node-origins'
> > table for node id 'a'".
> >
> > x Node has any successors (incl. copies) in a later revision
> > - This includes any obliteration in a non-head revision.
> > - Their reps and even node-revs will still refer to the obliterated
> > one so the repository will definitely be messed up.
> > - This is one of the next steps to implement.
> >
> > x FSFS
> > - I'm implementing only in BDB at the moment.
> >
> > x Remote RA methods
> > - I'm implementing only for RA-local at the moment.
> >
> >
> > There is also a bug in conjunction with trying to update the test's WC
> > from r10 (in which the test obliteration occurred) back to r9: it raises
> > a tree conflict but does not change the base rev to 9, and I can find no
> > way from the command line to resolve the conflict and update to r9 or
> > update to the new (obliterated) version of r10. I wonder if (for testing
> > purposes) we can avoid this bug by updating the WC to r9 before
> > performing the obliterate.
> >
> > Testing and other feedback greatly welcomed. Does it work for a
> > directory?
> >
> > - Julian
> >
> >
> >
>
>
>
Received on 2010-01-06 18:24:47 CET