How do I revert an unversioned file?

[Eric Siegerman]

On Thu, 2011-01-13 at 09:08 -0500, Eli Zaretskii wrote:
> > On some conflicts bzr renames files to file.OTHER / file.THIS.
> > You should see that fact in the bzr status output.
>
> Yes, I know about THIS and OTHER.  But none of them is a versioned
> file, right?

That's the thing; sometimes they *are* versioned.  That is, for
some types of conflicts, bzr doesn't just provide the content,
but appears to actually do the equivalent of "bzr mv foo foo.VARIANT",
maintaining its internal file-moved metadata in the process.

I don't completely understand this, but here's what I've learned
by experimentation.

I think the purpose is to preserve the file-id of whichever
variant you choose to keep.

I don't know a general rule for which variant(s), if any, will be
versioned in any given case, but as Alexandre says, bzr status will
tell you; e.g. in the OP's situation:
    added:         <----
      foo.OTHER    <----
    unknown:
      foo.BASE
    conflicts:
      Contents conflict in foo


It can be tricky at times to get the result you want.  Consider
the case where foo has been added independently on both branches:
    $ bzr merge
    Merging from remembered parent location /tmp/bt2/a/
    +N  foo
    R   foo => foo.moved
    Conflict adding file foo.  Moved existing file to foo.moved.
    1 conflicts encountered.

    $ bzr status
    added:               <----
      foo                <----
    renamed:             <----
      foo => foo.moved   <----
    conflicts:
      Conflict adding file foo.  Moved existing file to foo.moved.
    pending merge tips: (use -v to see all merge revisions)
      Eric Siegerman 2011-01-13 add on a

At this point, foo contains the variant from the "other" branch
(with that variant's file-id).  If you want to keep it, you can do:
    $ bzr rm foo.moved
    deleted foo.moved

    $ cat foo
    a-version
    $

If, on the other hand, you want to keep the variant from "this"
branch, revert foo:
    $ bzr merge		# I.e. we're starting afresh with the merge;
	...				# the previous "bzr rm" has *not* been done
	Conflicts blah blah blah

    $ bzr revert foo
    -D  foo
    R   foo.moved => foo

    $ cat foo
    b-version
    $

Be warned that if you instead revert foo.moved, you get:
    $ bzr merge		# Start afresh, as in the prev. example
	...
	Conflicts blah blah blah

    $ bzr revert foo.moved
    R   foo => foo.moved
    R   foo.moved => foo
    Conflict adding file foo.  Moved existing file to foo.moved.

which means you then have to "bzr rm foo.moved" to avoid checking
in *both* variants.

That one looks as though doing it again should swap them back,
but it doesn't; instead it gives:
	# Continuing on from the previous example
    $ bzr revert foo.moved
    -D  foo.moved

    $ cat foo
    b-version
    $

which is might be where you wanted to end up, but it's a
roundabout and confusing way to get there.

For me, this is always basically trial-and-error (with careful
thought preceding, to hopefully reduce the number of trials :-/


I'm thinking that a useful addition would be a
    bzr keep foo.VARIANT
command, which would do the equivalent of:
    bzr mv foo.VARIANT foo      # with foo.VARIANT's file-id
    bzr rm --keep foo.{other variants}
while automagically sorting out any unversioned-file and
file-in-the-way issues, or at least any unambiguous ones.  The
rm's should be --keep because one might want to manually merge in
bits of the other variants, and "bzr resolved" will get rid of
them anyway.

  - Eric