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
-----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----- enigmail. mozdev. org
6PHkACgkQJdeBCY SNAAOLqgCgyd+ QUbvh/IhIKtkuVv b9XaEW 4DA8XaF2N1pD1KO LH
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAko
t1wAoMIRuhnFjKs
=Gji2
-----END PGP SIGNATURE-----