Contents Conflict on Text File?

    > There are really two questions here.

    > If I look at
    > <http://doc.bazaar.canonical.com/development/en/user-reference/conflict-types-help.html>,
    > it seems to state that "contents conflicts" are conflict on
    > non-text files. So why am I getting them on text files?

Well, it says 'It can even happen with files that are deleted on one
side, and modified on the other.' and this part apply to text files as
well.

I agree we should find a better formulation there.

    > The second part of the question is based on what happens when I
    > get these conflicts (due to a merge). A .OTHER file is created,
    > which I understand. What baffles me is that the .OTHER file is
    > "added." Why does that happen?

So presumably here, the file was modified in the other branch and
deleted in the current one (you don't get a corresponding .THIS file
right ?). So there is a 'content conflict' because bzr can't decide
whether the right thing to do is to still delete the file OR take the
new modifications into account.

So bzr creates the .OTHER file so you can look at it.

Come to think of it, may be we should also create a .BASE file in this
case so you can more easily find what these modifications are...

    > Here's the output. Just to anticipate questions, no, the .OTHER does not exist in either repo as a checked-in file.

If you're talking about ACSES/C/MAIN.C.OTHER for example, then surely
ACSES/C/MAIN.C should exist in one of the branches no ?

main.c exists in both branches

You don't provide enough information then :-(

Could that be a case sensitive issue ?

You first said: MAIN.C and now you say main.c, are you using windows ?

Also you first said:

   no, the .OTHER does not exist in either repo as a checked-in file.

now you say:

  main.c exists in both branches

How should I reconcile these two contradictory statements ? Were you referring to another file in the first one ? Which one ?

Regarding the .OTHER existing, I meant that the literal "MAIN.C.OTHER" was not checked into the other repo, only "MAIN.C", because the question I was trying to ask was why does the MAIN.C.OTHER get "Added". ie. When there is a text conflict, MAIN.C.THIS, MAIN.C.BASE and MAIN.C.OTHER will be created on the filesystem, but those files are not marked as a pending addition. When there is a context conflict, not only is the MAIN.C.OTHER created on the filesystem, it is also marked as a pending addition to the repo. (+N ACSES/C/MAIN.C.OTHER) Why is that?

Regarding the case-sensitivity issue, I was thinking that might be the case too. But upon checking, both repos currently show MAIN.C as that, full upper case. However, at previous points in the repo, we HAVE had case sensitivity issues. On the branch being merged into, two revisions ago, this branch was merged into from the same source. At that point, this branch (being merged into) had "main.c" changed into "MAIN.C". Here the branches should match. So I expect on this subsequent merge, the case sensitivity issue should be resolved, but I don't fully understand why we have so many case sensitivity issues in the first place, so I could be wrong.

Yes, we are solely Windows.

Also, reading through all the thread, the .BASE file is created, but it is not "added". You had mentioned "maybe we should create a .BASE file." That actually does happen. But I was curious about the .OTHER being "added" so I didn't think of mentioning that at first.

Ha, then I suspect that somehow MAIN.C has been removed and main.c has been added.

This has create a new file ID which made bazaar thought there was 2 different files.

Using 'bzr st --show-ids' will show you what bzr consider the files to be.

In this case, you can also try 'bzr st -r-5.. --show-ids' or whatever revision range is appropriate in your case.

And there are probably bugs lying around regarding the case sensitivity, so if you find reproducing recipes for them, please file bugs !

They do have different IDs on the two branches, but are listed as MAIN.C on both:

  ACSES/C/MAIN.C main.c-20101110144810-meqrctkvn39vyptf-1

  ACSES/C/MAIN.C main.c-20100819182315-7nrbo9zexhgslmo2-35

so I'm not sure why they would be different as one comes directly from the other.

Anyway, that explains why it is a context conflict. But why is the .OTHER file "added"?

If you have two different file-ids, it probably means two developers added them (try searching your history with 'bzr log -v ACSES/C/MAIN.C' in both branches).

The .OTHER file is added because that's what happened in the branch you're merging from.

The other branch does NOT have a .OTHER file, they both only have MAIN.C. The .OTHER is created on the merge.

.BASE .THIS and .OTHER are suffixes added by *bzr*

When I say .OTHER or .THIS I meant file.OTHER or file.THIS whose contents or definition is the one the file had in either *this* branch (the target of the merge) or the *other* branch (the source of the merge).

Since in your case there are *2* MAIN.C bzr can't put them both in the same directory under the same name, so it adds a suffix to inform you about where the file is coming from.

This is described in 'bzr help conflict-types', you may find useful information there.

Understood. The .BASE file and a .OTHER file are created. Just like a text conflict (minus the .THIS). That is fine. But why is the .OTHER file *added* in addition to being *created* (unlike a text conflict)? Why not the .BASE file (which is just created, but not added)?

The only thing in Bazaar help that alludes to this is the sentence: 'It will appear that the "main
copy" has been renamed to THIS or OTHER.' But I don't understand why it doesn't just create .THIS and .OTHER files. Why does one have to be marked as a pending addition? That is what I can't wrap my head around.

The 'file.OTHER' is added because that's what the other branch did. It can't be added as 'file' since 'file' is already present hence the Content Conflict.

Now, in your case, it's a bit confusing because 'file' has really the same path, but as explained previously it's not the same file ID which is how the history is gathered for a given path even when it's renamed.

The ID allows merging changes from a file even if it appears under different names in the two branches. There is a work in progress about handling the case you're encountering better (two files with two different IDs but still the same path and a content highly similar). This is often referred to as the 'parallel import' problem where two people add the same files under the same paths in two different branches and try to merge.

That's why I asked you about the history of each file in each branch using --show-ids to better understand what happened. I hope you got a better understanding because all *I* can do is guess here.

So sometimes a file is renamed, and the other branch's file is added as the original name as in this case:

+N ACSES/Include/acsesprocessing.h
R ACSES/Include/acsesprocessing.h => ACSES/Include/acsesprocessing.h.moved

Othertimes, the local file is not renamed and the other branch's file is added as the .OTHER as in this case:

+N ACSES/C/MAIN.C.OTHER

But, I think, if I'm understanding your answer correctly, the *reason* for the file being put on the add list is because this is how Bazaar tracks file history under the hood? And it couldn't track the file history if it were just created, so it must be added? Is this the reason?

I would think that both file histories would just become the new file, but I suppose there is always the case where you take the MAIN.C.OTHER and do a Bazaar rename to Main2.C or something because you really wanted two different files...

Thanks Vincent Ladeuil, that solved my question.