My bzr diff output for Emacs is now 6 MB

My bzr diff output for Emacs is now 6 MB

[Lennart Borgman]

It looks like bzr failed to merge date changes etc. Why does this happen?

Re: My bzr diff output for Emacs is now 6 MB

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 2 Feb 2011 04:40:32 +0100
> 
> It looks like bzr failed to merge date changes etc.

What do you mean by "merging date changes"?

Re: My bzr diff output for Emacs is now 6 MB

[Lennart Borgman]

On Wed, Feb 2, 2011 at 5:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Wed, 2 Feb 2011 04:40:32 +0100
>>
>> It looks like bzr failed to merge date changes etc.
>
> What do you mean by "merging date changes"?


The only difference I saw in several files where the date changes in
the headers.

However now - after a new checkout - things seems back to normal. It
looks like bzr needs several turns sometimes to do the job.

This was for my emacsw32 branch. There was no such problem for just
the trunk checkout.

Re: My bzr diff output for Emacs is now 6 MB

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 2 Feb 2011 05:07:12 +0100
> Cc: emacs-devel@gnu.org
> 
> On Wed, Feb 2, 2011 at 5:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Date: Wed, 2 Feb 2011 04:40:32 +0100
> >>
> >> It looks like bzr failed to merge date changes etc.
> >
> > What do you mean by "merging date changes"?
> 
> 
> The only difference I saw in several files where the date changes in
> the headers.

What do you mean by "headers"?

> However now - after a new checkout - things seems back to normal. It
> looks like bzr needs several turns sometimes to do the job.

That'd be news to me.  But it's hard to say anything intelligent
without seeing at least one instance of these "failed merges".

Re: My bzr diff output for Emacs is now 6 MB

[Lennart Borgman]

On Wed, Feb 2, 2011 at 1:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Wed, 2 Feb 2011 05:07:12 +0100
>> Cc: emacs-devel@gnu.org
>>
>> On Wed, Feb 2, 2011 at 5:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Date: Wed, 2 Feb 2011 04:40:32 +0100
>> >>
>> >> It looks like bzr failed to merge date changes etc.
>> >
>> > What do you mean by "merging date changes"?
>>
>>
>> The only difference I saw in several files where the date changes in
>> the headers.
>
> What do you mean by "headers"?

It was those lines that differed for every file:

;; Copyright (C) 2004-2011  Free Software Foundation, Inc.

But that was probably not all.


>> However now - after a new checkout - things seems back to normal. It
>> looks like bzr needs several turns sometimes to do the job.
>
> That'd be news to me.  But it's hard to say anything intelligent
> without seeing at least one instance of these "failed merges".

I did not save this one, but I have an old output from bzr diff from
2010-12-29 which is 6 MB. The diff is done after the merge and against
the checked out trunk.

Unfortunately the bzr diff output does not contain any details about
what revisions was diffed. (Is not that a big omitting?)

Re: My bzr diff output for Emacs is now 6 MB

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 2 Feb 2011 13:27:59 +0100
> Cc: emacs-devel@gnu.org
> 
> It was those lines that differed for every file:
> 
> ;; Copyright (C) 2004-2011  Free Software Foundation, Inc.

That's when the Copyright notices were updated for all the files,
to include 2011, because a new year has begun.  What was the problem
with these lines?

> I did not save this one, but I have an old output from bzr diff from
> 2010-12-29 which is 6 MB. The diff is done after the merge and against
> the checked out trunk.

So what is the problem here?  If every file has its first line or two
changed, the diff of 6MB is normal.

> Unfortunately the bzr diff output does not contain any details about
> what revisions was diffed. (Is not that a big omitting?)

"bzr diff" always diffs against the current version by default, which
you can see with "bzr revno".  If you give non-default -rREVNO
arguments to "bzr diff", then presumably you already know the
revisions yourself.

Re: My bzr diff output for Emacs is now 6 MB

[Stefan Monnier]

> I did not save this one, but I have an old output from bzr diff from
> 2010-12-29 which is 6 MB. The diff is done after the merge and against
> the checked out trunk.

You probably didn't do the diff you thought you were doing.  A common
case for is to do the diff before committing: Bzr stupidly ignores the
pending merges when computing the ancestry, so a "diff -rsubmit:"
applied after a merge but before the corresponding commit will show
misleading results.

> Unfortunately the bzr diff output does not contain any details about
> what revisions was diffed. (Is not that a big omitting?)

IIRC I filed a bug about that (or added to a pre-existing bug about
that) a few years ago.  Please look for that bug and add your voice
to it.


        Stefan

Re: My bzr diff output for Emacs is now 6 MB

[Lennart Borgman]

On Wed, Feb 2, 2011 at 5:08 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I did not save this one, but I have an old output from bzr diff from
>> 2010-12-29 which is 6 MB. The diff is done after the merge and against
>> the checked out trunk.
>
> You probably didn't do the diff you thought you were doing.  A common
> case for is to do the diff before committing: Bzr stupidly ignores the
> pending merges when computing the ancestry, so a "diff -rsubmit:"
> applied after a merge but before the corresponding commit will show
> misleading results.

Hm, I thought so, but I am using this for merging and the diff is done later:

  @setlocal
  @set DEVHOME=bld

  @pushd %DEVHOME%\emacs\trunk
  bzr update
  @popd

  @pushd %DEVHOME%\emacs\emacsw32
  bzr merge
  bzr commit -m "Merge from trunk"
  @popd


>> Unfortunately the bzr diff output does not contain any details about
>> what revisions was diffed. (Is not that a big omitting?)
>
> IIRC I filed a bug about that (or added to a pre-existing bug about
> that) a few years ago.  Please look for that bug and add your voice
> to it.

I will if you tell me how to find it.