Comment 4 for bug 322767

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 322767] Re: MYSQL/BZR - P3: How to avoid that people commit .OTHER/.BASE/.THIS/.moved files?

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

Martin Pool wrote:
> Regarding the .BASE/.THIS/.OTHER files, I'm not sure I understand the
> case where they could end up being committed. If you get a conflict
> then do
>
> bzr add foo.c.OTHER
> bzr resolve foo.c
> bzr commit

I don't know if you realize, Martin, but if you get a content conflict
with a deleted file, I believe the new file ends up as a versioned file
named foo.c.OTHER

$ bzr merge ../y
+N a.OTHER
Contents conflict in a
1 conflicts encountered.

jameinel@samus ~/dev/,tmp/x {x}
$ bzr st
added:
  a.OTHER
unknown:
  a.BASE
conflicts:
  Contents conflict in a
pending merge tips: (use -v to see all merge revisions)
  John Arbash Meinel 2009-06-18 bar

Note that there is no "a.THIS" file, because the file was deleted.

One issue is that we just say "Contents conflict" and not "deleted file
was modified", or something that the user can then understand the
conflict. (When discussing this in the past, it required a WT format
bump because we have to add more information to the Conflict structure
at the time of merge, so that 'status' can then report it.)

Anyway, that is a "trivial" way to get a versioned .OTHER. If someone
does "bzr resolve a.OTHER" or "bzr resolve a" (or bzr resolve --all, I
think) it goes away. The file is still marked as added, but the object
on disk is deleted. (Doing touch a.OTHER shows it as added again.)

John
=:->

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

iEYEARECAAYFAko6PHkACgkQJdeBCYSNAAOLqgCgyd+QUbvh/IhIKtkuVvb9XaEW
t1wAoMIRuhnFjKs4DA8XaF2N1pD1KOLH
=Gji2
-----END PGP SIGNATURE-----