[MERGE] Conflict handling docs
Aaron Bentley
aaron.bentley at utoronto.ca
Tue Jul 24 22:25:55 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Westby wrote:
> On (23/07/07 18:43), Aaron Bentley wrote:
>> +Some operations, like merge, revert and pull, modify the contents of your
>> +working tree. But because the changes are programmatically generated, they
>> +can come into conflict with the actual state of your working tree. Many
>> +kinds of changes can be combined programmatically, but sometimes only a
>> +human can determine the right thing to do.
>
> I don't like starting that sentence with "But".
I'm a moderate. If it makes the sentence flow better, I'll start it
with "But" or "And".
> Also it isn't clear to
> me what "the changes" refers to. Can I suggest
Thanks. Taken.
> Here and in the other sections you use "foo" in the message, but refer
> to "FILE" in the description, it would be good if they were the same.
Okay. I've got with FILE throughout.
> "THIS" etc. are sometimes quoted, sometimes not, perhaps it should be
> consistent where that makes sense.
Sure.
> Also I'm not sure which is the target tree.
It's the tree you are merging into. It's not the THIS tree-- that
describes the state before merging. It's not the current working tree--
the target tree of push (on a local path) is the tree you're pushing into.
> Would it be helpful to have an example conflict, and perhaps show what a
> resolved version might look like.
Done.
> Also I think it might be worthwhile to
> explain that the conflict markers must be removed, that is that the file
> should be left exactly as the user would like it to be committed. This
> is probably redundant for anyone that has ever used another system, but
> a new user probably wont understand.
Okay.
> You say that it emits '"THIS", "OTHER" and "BASE" files' but what if the
> conflict is a symlink or a directory?
I'm using file in the sense that includes symlinks and directories, but
I've added a note to that effect.
>
>> +Sometimes Bazaar will attempt to create a file whose parent directory is not
>> +versioned. This happens when the directory has been deleted in the target,
>> +but has a new child in the source, or vice versa. In this situation, Bazaar
>> +will version the parent directory as well. You may rename either file, if you
>
> What does "either file" refer to?
Either the directory or the file.
>> +Parent Loop
>> +===========
>> +In this situation, Bazaar will cancel the move, and leave "a" in "b".
>
> Does this not require explicit resolution, but resolution may be desired?
Requires resolution. Fixed.
> Worth telling them how they can let us know? Perhaps point them at the
> Launchpad file a bug page?
Okay.
>> + * ``bzr checkout`` now honours -r when reconstituting a working tree.
>> + It also honours -r 0. (Aaron Bentley, #127708)
>> +
>
> This looks like the wrong NEWS entry, and a bugfix that isn't for this
> merge below.
I had submitted that merge, but my bzr.dev didn't reflect it at that
time. Fixed now.
>> +* `Conflict handling <conflicts.htm>`_
>> +
>
> Is it worth having a single line description like the other entries?
Alright.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGpm5j0F+nu1YWqI0RAk0hAJ9SsGc/6jZpMZx6Uhysg9lJ5l6+2ACeJ5/e
taOuGmUCoM/6kXcFA0lQQ70=
=3cwc
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conflict-doc2.patch
Type: text/x-patch
Size: 13459 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070724/10f40c46/attachment-0001.bin
More information about the bazaar
mailing list