Re: bzr commit raises a weird conflict

[Eli Zaretskii]

> Date: Tue, 9 Apr 2013 12:28:04 +0200
> From: Giorgos Keramidas <address@hidden>
> Cc: Christopher Schmidt <address@hidden>
> 
> > "~$ bzr commit" complains about a conflict.

Bastien should have seen this conflict announced when you updated or
merged from upstream.  He probably didn't notice that, but he can look
that up in your ~/.bzr.log entry for the time of update/merge.

> > "~$ bzr conflicts" yields:
> >   Conflict: can't delete leim/ja-dic because it is not empty.  Not deleting.
> >
> > I first ran "~$ make maintainer-clean" before trying to commit,
> > because I did build Emacs from this directory.

maintainer-clean cannot resolve this, because the problem is not in
the file system.  The problem is in the history meta-data.  Deleting
files or directories manually, when such conflicts happen, doesn't
help, because bzr cannot detect when these conflicts are resolved; you
must tell it explicitly about the resolution, using the "bzr resolve"
command.  The documentation I mentioned in my other mail in this
thread says that bzr needs to be told when the conflict is resolved
(unlike with text conflicts, where it can detect resolution
automatically).

> That's because leim/ja-dic/ was removed recently, but if you are merging
> in an unclean checkout (with build output from previous builds), bzr
> notices that:
> 
>   (a) The directory should be removed as part of the merge
>   (b) The directory is not empty
> 
> So it takes the safer approach of aborting the merge with a conflict,
> instead of blindly removing the directory.
> 
> This is an artifact of the fact that bzr likes tracking directory
> changes too, as part of the branch history.  In this case it acts a bit
> silly, because there are *no* files tracked remaining after the
> directory is fully removed from a branch, so it should just go ahead and
> remove the directory from the branch, but leave the filesystem intact.

It is not silly.  "bzr up" merges the upstream with what you have, and
also leaves intact any unversioned files you happen to have. Bazaar
cannot know what is the unversioned file in the directory that was
deleted upstream.  It could just be a new file you intend to add to
version control, but just didn't yet "bzr add".  If bzr removes the
directory from the history metadata, that file would become an
orphan--you won't be able to add it, because its parent directory is
gone.  (That directory and its history could be recovered, of course,
but doing that is non-trivial, either.)  So bzr punts and leaves it to
you to resolve the snafu.

If this branch is never used to add new files, Bastien can prevent
this nuisance by setting the bzr.transform.orphan_policy option, see
the description in "bzr help conflict-types".

> Since there are no files left in the originally tracked directory,
> future merges or updates will not care about this path anyway.

"bzr update" preserves unversioned files as well, because that could
be work in progress that you don't want to lose.