* Re: Merge conflict cookie in dired.el (current HEAD in bzr)
2012-09-28 7:27 ` Eli Zaretskii
@ 2012-09-28 7:36 ` Bastien
2012-09-28 10:02 ` Andreas Schwab
2012-09-28 15:30 ` Juri Linkov
2 siblings, 0 replies; 8+ messages in thread
From: Bastien @ 2012-09-28 7:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Glenn Morris <rgm@gnu.org> writes:
>>
>> > Bastien wrote:
>> >
>> >> There is this merge conflict indication in dired.el
>> >> which prevents Emacs from building:
>> >
>> > That is local to your copy.
>>
>> Indeed. No idea how this ended up here.
>
> Probably like this:
>
> . "bzr up"
> . build Emacs, which changed dired.el due to autoloads
> . "bzr up", which brought in dired.el where the same autoloads were
> already updated, but the time stamp was different. Bzr told you
> that there text conflicts, but you didn't notice that.
>
> In general, it is advisable to run "bzr st" from time to time,
> preferably after the build that you do after "bzr up", to see if any
> versioned files changed due to autoloads. If some of them did, either
> commit those files (preferred), or "bzr revert" and rebuild, then wait
> for someone else to commit the modified autoloads.
Thanks for the info Eli, will check this when I build again.
--
Bastien
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Merge conflict cookie in dired.el (current HEAD in bzr)
2012-09-28 7:27 ` Eli Zaretskii
2012-09-28 7:36 ` Bastien
@ 2012-09-28 10:02 ` Andreas Schwab
2012-09-28 15:30 ` Juri Linkov
2 siblings, 0 replies; 8+ messages in thread
From: Andreas Schwab @ 2012-09-28 10:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Bastien, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> If some of them did, either commit those files (preferred),
Glenn already does that, automagically.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Merge conflict cookie in dired.el (current HEAD in bzr)
2012-09-28 7:27 ` Eli Zaretskii
2012-09-28 7:36 ` Bastien
2012-09-28 10:02 ` Andreas Schwab
@ 2012-09-28 15:30 ` Juri Linkov
2012-09-28 18:15 ` Paul Eggert
2 siblings, 1 reply; 8+ messages in thread
From: Juri Linkov @ 2012-09-28 15:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Bastien, emacs-devel
> In general, it is advisable to run "bzr st" from time to time,
> preferably after the build that you do after "bzr up", to see if any
> versioned files changed due to autoloads. If some of them did, either
> commit those files (preferred), or "bzr revert" and rebuild, then wait
> for someone else to commit the modified autoloads.
There is a related problem. When "bzr merge" says there are conflicts,
I rush to edit reported files to fix conflicts, but this puts the repository
into a broken state, because when I start editing, the "bzr merge" command
is not yet finished. Bzr is so slow that it reports conflicts and
continues its work for another 10-20 seconds. When I edit files
during this time and save them, vc-bzr.el reports an error, after that
only manually running "bzr resolve" helps to resolve this situation.
Maybe like compile.el displays the running process status in the mode line
with the `compilation-mode-line-run' face, comint-mode could use the same
face in the mode line to highlight the process status ":run" (if there are
no better ideas).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Merge conflict cookie in dired.el (current HEAD in bzr)
2012-09-28 15:30 ` Juri Linkov
@ 2012-09-28 18:15 ` Paul Eggert
0 siblings, 0 replies; 8+ messages in thread
From: Paul Eggert @ 2012-09-28 18:15 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
On 09/28/2012 08:30 AM, Juri Linkov wrote:
> When "bzr merge" says there are conflicts,
> I rush to edit reported files to fix conflicts
Eeuuw. Don't do that! The right way to think about
'bzr' is that it's a good time to get a cup of coffee.
Or tea. Or think. Or maybe just look out the window, if
you have a window. But don't modify source files while
'bzr' is doing its thing -- that'll just cause trouble.
I often get some of my best little hacking ideas
while waiting for bzr to finish.
^ permalink raw reply [flat|nested] 8+ messages in thread