bzr commit raises a weird conflict

bzr commit raises a weird conflict

[Bastien]

I wanted to push a tiny docstring bugfix (bug#14163) but could not.

"~$ bzr commit" complains about a conflict.

"~$ 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.

How can I resolve this "conflict"?

I know it safer to build from a dedicated branch, and to use a clean
branch for commits, but still, I don't understand what's wrong.

Thanks for any help,

-- 
 Bastien

Re: bzr commit raises a weird conflict

[Christopher Schmidt]

Bastien <bzg@gnu.org> writes:
> How can I resolve this "conflict"?
>
> I know it safer to build from a dedicated branch, and to use a clean
> branch for commits, but still, I don't understand what's wrong.

I don't understand what's wrong, either.

    bzr resolve --take-other

solved it for me.  This is probably another bug in bzr.

        Christopher

Re: bzr commit raises a weird conflict

[Bastien]

Hi Christopher,

Christopher Schmidt <christopher@ch.ristopher.com> writes:

>     bzr resolve --take-other
>
> solved it for me.

It did for me as well, thanks for the trick.

I've pushed the fix.

-- 
 Bastien

Re: bzr commit raises a weird conflict

[Giorgos Keramidas]

On 2013-04-09 09:50, Bastien <bzg@gnu.org> wrote:
> I wanted to push a tiny docstring bugfix (bug#14163) but could not.
>
> "~$ bzr commit" complains about a conflict.
>
> "~$ 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.
>
> How can I resolve this "conflict"?

On 2013-04-09 09:42, Christopher Schmidt <christopher@ch.ristopher.com> wrote:
> Bastien <bzg@gnu.org> writes:
> > How can I resolve this "conflict"?
> >
> > I know it safer to build from a dedicated branch, and to use a clean
> > branch for commits, but still, I don't understand what's wrong.
>
> I don't understand what's wrong, either.
>
>     bzr resolve --take-other
>
> solved it for me.  This is probably another bug in bzr.

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.
Since there are no files left in the originally tracked directory,
future merges or updates will not care about this path anyway.

Running 'bzr resolve --take-other' basically tells bzr to ignore
whatever happens to exist in the filesystem because of the local branch
and consider the 'source branch' the authoritative source of what it
should do with leim/ja-dic/.  And it solves this minor merge problem ;)

--
Giorgos Keramidas; gkeramidas@gmail.com

Re: bzr commit raises a weird conflict

[Bastien]

Hi Giorgos,

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> 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.
> Since there are no files left in the originally tracked directory,
> future merges or updates will not care about this path anyway.
>
> Running 'bzr resolve --take-other' basically tells bzr to ignore
> whatever happens to exist in the filesystem because of the local branch
> and consider the 'source branch' the authoritative source of what it
> should do with leim/ja-dic/.  And it solves this minor merge problem
> ;)

Thanks for the detailed explanation -- will remember this next time.

-- 
 Bastien

Re: bzr commit raises a weird conflict

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Tue,  9 Apr 2013 09:42:39 +0100 (BST)
> 
> Bastien <bzg@gnu.org> writes:
> > How can I resolve this "conflict"?
> >
> > I know it safer to build from a dedicated branch, and to use a clean
> > branch for commits, but still, I don't understand what's wrong.
> 
> I don't understand what's wrong, either.

The directory is removed in the master repository, but not in the
local branch.  That's a conflict that prevents a clean merge.

>     bzr resolve --take-other
> 
> solved it for me.  This is probably another bug in bzr.

It's not a bug, and the above is precisely the way to resolve such
conflicts (of course, you could also use --take-mine, but in this case
that would be wrong).

Bastien, next time you have such non-text conflicts, type

  bzr help conflict-types

and read there (it's a long entry, so redirect to a pager or to an
Emacs buffer).  In particular, this specific conflict is described
under "Deleting parent".

Re: bzr commit raises a weird conflict

[Eli Zaretskii]

> Date: Tue, 9 Apr 2013 12:28:04 +0200
> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Cc: Christopher Schmidt <christopher@ch.ristopher.com>
> 
> > "~$ 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.

Re: bzr commit raises a weird conflict

[Christopher Schmidt]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Christopher Schmidt <christopher@ch.ristopher.com>
>>     bzr resolve --take-other
>> solved it for me.  This is probably another bug in bzr.

Hi Eli,

thank you very much for your explanation.  I should have investigated
before calling in another bug.  I will be more careful next time.

My apologies for the noise.

Greetings,
        Christopher

Re: bzr commit raises a weird conflict

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Wed, 10 Apr 2013 08:38:19 +0100 (BST)
> 
> thank you very much for your explanation.  I should have investigated
> before calling in another bug.  I will be more careful next time.
> 
> My apologies for the noise.

It was not noise: you helped Bastien to solve his problem.  No need to
apologize for that.

Re: bzr commit raises a weird conflict

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> It was not noise: you helped Bastien to solve his problem.  No need to
> apologize for that.

Indeed, no apologies needed -- thanks all for the info.

-- 
 Bastien