Conflicts due to independently creating identical files

[Andrew S. Townley]

Hi,

I couldn't see that there was ever any response or resolution to this particular problem (from 2007).  I've been a bzr + unison user for a number of years, but it seems like I'm hitting this issue more and more these days.

In my case, I synchronize the entire bzr trees.  However, what I've also noticed recently is that 
occasionally bzr "forgets" who I am.  I never used to use a .bzr file, but now I have to.  I don't know if they're related or not.

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?

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.

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.

Thanks in advance.

ast
--
Andrew S. Townley <ast at atownley.org>
http://atownley.org

Iain Murray <transient.mail <at> gmail.com> writes:

> 
> Hi all,
> 
> I have a problem with conflicts when two copies of a project
> independently obtain copies of the same file. I'll give a specific
> example and then ask for some advice.
> 
> My usage: I have bzr-managed projects on a work machine and bound
> branches on my laptop. I use the bzr+ssh:// transport.
> 
> Say I add a new file ("new_file") on my laptop and commit. Now, for my
> own peculiar reasons, I give the server its own copy of "new_file"
> with identical contents and properties. I then run an update on the
> server:
> 
> % bzr update
> +N  new_file
> Conflict adding file new_file.  Moved existing file to new_file.moved.
> 1 conflicts encountered.
> Updated to revision 1.
> 
> It's hard to believe this should be a conflict when both ends are in
> complete agreement about "new_file". I appreciate the conflict is
> because one end has a file ID for it and the other doesn't. But as a
> user, it would be nice if this "Just Worked", for the same reasons as
> in this related bug:
>     https://bugs.launchpad.net/bzr/+bug/90569
> Couldn't the end with the unversioned file just silently go to
> versioning it with the same file ID as the other end?
> 
> I may be interested in trying to fix this, although would happily step
> aside to someone that already knows the bzr code well. Some questions:
> Is this a known/discussed issue? (I didn't find it, but the archives
> are large.) Are there any subtle reasons why fixing this would be
> hard?
> 
> Thanks,
> Iain.
> 
> PS As a separate issue, this happens to me a lot for a reason I'm sure
> I'm going to be told is stupid. I synchronize my laptop and work
> machine home directories (except .bzr directories) with unison. I run
> a separate hack to create and bind .bzr directories on each machine
> whenever I start versioning a new project. Whenever I run unison it
> looks as though someone came in and made a load of identical changes
> on both machines. Normally update copes fine with this (an advertised
> feature of bzr), unless the changes involved new files.
> 
> Probably I "shouldn't do that". But apart from this issue (which
> actually I can hack around reasonably with another shell script), it
> works well for me and does what I want. I'd like to choose when to
> commit or otherwise fight with bzr, not be forced to on all my
> projects just because I'm taking my laptop away from the network. With
> unison I can sync all my files at once, whatever state they're in, and
> whether they're in a versioned project or not. If anyone has a better
> way of achieving this though, I'm open to suggestions.
> 
> 



--
Andrew S. Townley <ast at atownley.org>
http://atownley.org