[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