unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* bzr commit raises a weird conflict
@ 2013-04-09  7:50 Bastien
  2013-04-09  8:42 ` Christopher Schmidt
  2013-04-09 10:28 ` Giorgos Keramidas
  0 siblings, 2 replies; 10+ messages in thread
From: Bastien @ 2013-04-09  7:50 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09  7:50 bzr commit raises a weird conflict Bastien
@ 2013-04-09  8:42 ` Christopher Schmidt
  2013-04-09  9:37   ` Bastien
  2013-04-09 15:13   ` Eli Zaretskii
  2013-04-09 10:28 ` Giorgos Keramidas
  1 sibling, 2 replies; 10+ messages in thread
From: Christopher Schmidt @ 2013-04-09  8:42 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09  8:42 ` Christopher Schmidt
@ 2013-04-09  9:37   ` Bastien
  2013-04-09 15:13   ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: Bastien @ 2013-04-09  9:37 UTC (permalink / raw)
  To: Christopher Schmidt; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09  7:50 bzr commit raises a weird conflict Bastien
  2013-04-09  8:42 ` Christopher Schmidt
@ 2013-04-09 10:28 ` Giorgos Keramidas
  2013-04-09 11:23   ` Bastien
  2013-04-09 15:31   ` Eli Zaretskii
  1 sibling, 2 replies; 10+ messages in thread
From: Giorgos Keramidas @ 2013-04-09 10:28 UTC (permalink / raw)
  To: Bastien, emacs-devel; +Cc: Christopher Schmidt

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09 10:28 ` Giorgos Keramidas
@ 2013-04-09 11:23   ` Bastien
  2013-04-09 15:31   ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: Bastien @ 2013-04-09 11:23 UTC (permalink / raw)
  To: Giorgos Keramidas; +Cc: Christopher Schmidt, emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09  8:42 ` Christopher Schmidt
  2013-04-09  9:37   ` Bastien
@ 2013-04-09 15:13   ` Eli Zaretskii
  2013-04-10  7:38     ` Christopher Schmidt
  1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2013-04-09 15:13 UTC (permalink / raw)
  To: Christopher Schmidt; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09 10:28 ` Giorgos Keramidas
  2013-04-09 11:23   ` Bastien
@ 2013-04-09 15:31   ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2013-04-09 15:31 UTC (permalink / raw)
  To: Giorgos Keramidas; +Cc: bzg, christopher, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-09 15:13   ` Eli Zaretskii
@ 2013-04-10  7:38     ` Christopher Schmidt
  2013-04-10 15:31       ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Christopher Schmidt @ 2013-04-10  7:38 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-10  7:38     ` Christopher Schmidt
@ 2013-04-10 15:31       ` Eli Zaretskii
  2013-04-12  8:49         ` Bastien
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2013-04-10 15:31 UTC (permalink / raw)
  To: Christopher Schmidt; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: bzr commit raises a weird conflict
  2013-04-10 15:31       ` Eli Zaretskii
@ 2013-04-12  8:49         ` Bastien
  0 siblings, 0 replies; 10+ messages in thread
From: Bastien @ 2013-04-12  8:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Christopher Schmidt, emacs-devel

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-04-12  8:49 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-09  7:50 bzr commit raises a weird conflict Bastien
2013-04-09  8:42 ` Christopher Schmidt
2013-04-09  9:37   ` Bastien
2013-04-09 15:13   ` Eli Zaretskii
2013-04-10  7:38     ` Christopher Schmidt
2013-04-10 15:31       ` Eli Zaretskii
2013-04-12  8:49         ` Bastien
2013-04-09 10:28 ` Giorgos Keramidas
2013-04-09 11:23   ` Bastien
2013-04-09 15:31   ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).