Bazaar doesn't notice/care if you try to version-control *.THIS, *.BASE, *.OTHER or *.moved

From IRC - more context:
---
09:22 < lifeless> sandsmark: could you file a bug? we should be more
graceful/informative about that particular case.
09:22 < sandsmark> lifeless: well, 1.5 is pretty old
09:22 < lifeless> even so
09:22 < sandsmark> ok
09:23 < lifeless> if its fixed already it will be easy to close ;)
09:23 < sandsmark> heh, ok :-)
09:23 < lifeless> but while I suspect we have a bug thats similar to
this already, I'm fairly sure we haven't actioned it.
09:23 < lifeless> so at worst this will be a dup and add data to the
frequency people hit it.
09:24 < sandsmark> lifeless: uhm, is this really a bug, though? I would
rather say the problem is with etckeeper, adding all files
indiscriminately
09:24 < sandsmark> (the real question is where the conflict comes from,
though)
09:25 < lifeless> bzr could help - it could say 'this is a dangerous
file to add', it could, on conflicts, not conflict on that file but
instead know it can overwrite it;it could adjust the conflict path it
uses
----

There are several ways to look at this bug, but I think in that case, it's due to etckeeper adding files, generated by bzr to help resolve conflicts, and seen as unknown.

Can you explain what workflow you used that ended up in such files being added ?
In particular, how did you solve (or not !) the conflicts that led to the creation of these files ?

Anyway, I think the description of this is quite good as bzr shouldn't (at least by default) accept to 'add' files that are known to be associated with existing conflicts.

‘bzr commit -m "foo, bar"; bzr uncommit’, then add in etckeeper, and bzr 1.5 crashing due to encoding errors (they went away when upgrading to 1.16).

(I'm not sure of the exact order of events, I just got to clean up the mess.)

@Martin: Thanks for the feedback, so indeed, there was a 'bzr add'.

Marking high as it's a first line of defense against subsequent surprising behaviors (once the files are added, subsequent conflicts on the involved files become really obscure).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
> @Martin: Thanks for the feedback, so indeed, there was a 'bzr add'.
>
> Marking high as it's a first line of defense against subsequent
> surprising behaviors (once the files are added, subsequent conflicts on
> the involved files become really obscure).
>

So one possibility is to add .THIS, .BASE, .OTHER to the default ignore
list.

The good and bad is that "bzr add" won't default to adding them, but
"bzr status" won't default to showing them. (You will hopefully a
conflict entry for the given file, though.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqJXm4ACgkQJdeBCYSNAANNtwCfc39gTLtmiqCytqVcvdGHuSDi
5HsAn1gsHu1zoVN4AJ5bsJ4cAFMAMG8e
=4BUN
-----END PGP SIGNATURE-----

>>>>> John A Meinel <> writes:

    > Vincent Ladeuil wrote:
    >> @Martin: Thanks for the feedback, so indeed, there was a 'bzr add'.
    >>
    >> Marking high as it's a first line of defense against subsequent
    >> surprising behaviors (once the files are added, subsequent conflicts on
    >> the involved files become really obscure).
    >>

    > So one possibility is to add .THIS, .BASE, .OTHER to the default ignore
    > list.

    > The good and bad is that "bzr add" won't default to adding
    > them, but "bzr status" won't default to showing them. (You
    > will hopefully a conflict entry for the given file,
    > though.)

One problem with that approach is that it doesn't make any
difference between a file genuinely named 'MY.BASE' and a bzr
conflict-related-generated file named 'MY.BASE'

What I have in mind instead is to add a check, from the actual,
existing, conflicts that 'MY.BASE' can't be added if 'MY' is in
conflicts. I.e. bzr knows (for a moderately sure value of knows)
that MY.BASE has been generated to help the user resolve a
conflict involving 'MY', in that case, it shouldn't accept
silently (or ever) to 'bzr add' it.

We can discuss how strong bzr will resist add'ing such files
(involved in a conflict) around the lines of: refusing to add
except if the files are specifically provided as parameters.

John A Meinel wrote:

> So one possibility is to add .THIS, .BASE, .OTHER to the default ignore
> list.
>
> The good and bad is that "bzr add" won't default to adding them, but
> "bzr status" won't default to showing them. (You will hopefully a
> conflict entry for the given file, though.)

I find it odd in Explorer that you always see both when a conflict exists:

* first the conflict at the top of the GUI status report
* then the BASE/OTHER/THIS files in the Unversioned section

Resolving the conflict is a mandatory action and it's that resolution
process (and only that process IIUIC) that cleans up these files. Yet,
like every other unversioned file, Explorer suggests adding, deleting or
ignoring these. :-(

It's feels wrong that they even appear but I'd prefer not to add special
handling in the GUI when I can't see a good reason for not fixing the
command line UI as well.

So my vote is to add them to the ignore list. That fixes both status and
accidental additions, doesn't it?

Ian C.

On Mon, 2009-08-17 at 23:08 +0000, Ian Clatworthy wrote:
>
> So my vote is to add them to the ignore list. That fixes both status
> and
> accidental additions, doesn't it?

Not really, as 'add MY.BASE' will still succeed.

I like Vincents idea of cross-referencing the tree's conflict metadata.

-Rob

Not a duplicate because there are far too many little details involved to solve them all with a single bug.
This bug is clearly related to #322767, but not a duplicate.