Conflicts due to independently creating identical files

[vila]

>>>>> Andrew S Townley <ast at atownley.org> writes:

<snip/>

    > In my case, I synchronize the entire bzr trees.  However, what
    > I've also noticed recently is that occasionally bzr "forgets" who
    > I am.

This seems weird, are you setting 'email' in 'bazaar.conf' or
'branch.conf' ?

If you do it in the later and then sync your tree from a host where you
used the former, then that would explain it.

    > I never used to use a .bzr file, but now I have to.  I don't know
    > if they're related or not.

What .bzr "file" are you referring to here ?

    > I regularly do development across a few machines for various
    > reasons, and this is becoming a very annoying problem for me.  Is
    > it possible in this scenario to do a diff on the file and if they
    > are identical to not issue this conflict situation?

This is worked on as a work around to the so-called 'parallel import'
problem.

When a file is added to bzr, it receives a file-id which is then used to
track the renames and ensure that the modifications made on the file
after various renamings are still recognized as being about this precise
file.

When a file is added in two (or more) different branches, bzr generates
a conflict (a 'Content Conflict') to indicate that there is no automated
way to decide which file-id should be kept (and the associated history).

    > My standard resolution process is to do a find . -name '*.moved'
    > -exec rm {} \; and then resolve the conflicts.  I know the files
    > are identical because they're synchronized with unison.

If you maintain the trees yourself, you may want to resync their
histories too, that would get rid of the conflicts entirely. Also using
Unison (based on rsync right ?) should not give better results than 'bzr
pull' (especially if you use the recommended stable 2a format).

    > I would really be interested in hearing why the above proposal of
    > doing a check for identical files isn't a valid way to avoid the
    > problem.

Well, for the edge case where the files have been created independently
and are then tracked by bzr, syncing the histories after the first
conflict resolution is the cleanest way.

What makes the workaround you propose less reliable is when the files
keep being modified under their original file-id. This requires more
care and more work and hasn't been addressed (yet, but hopefully will,
soon).

        Vincent

--913EB1815F4.1291895479/axe--