bzr log DIR should show changes under dir

This can be seen as a particular subcase of "bzr log should accept more than one file".

This isn't really practical without changes to the inventory format.

On Wed, 2008-03-12 at 20:50 +0000, Aaron Bentley wrote:
> This isn't really practical without changes to the inventory format.
>
> ** Changed in: bzr
> Importance: High => Medium
>

Does the practicality change the importance of it? In my
opinion it's an important thing to have.

Or are you using Importance as priority?

Thanks,

James

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Westby wrote:
> On Wed, 2008-03-12 at 20:50 +0000, Aaron Bentley wrote:
>> This isn't really practical without changes to the inventory format.
>>
>> ** Changed in: bzr
>> Importance: High => Medium
>>
>
> Does the practicality change the importance of it? In my
> opinion it's an important thing to have.
>
> Or are you using Importance as priority?

I am using importance as a combination of severity and priority, which
is how the Launchpad team say it's supposed to be used.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH4dEN0F+nu1YWqI0RAu6eAJ9tu6wqhMlbfO/uvhmOzGIMTAeZRACcCjPX
K0a+c9N9bHAwTIWLBuWxhD4=
=BvlJ
-----END PGP SIGNATURE-----

On Thu, 2008-03-20 at 02:50 +0000, Aaron Bentley wrote:
> I am using importance as a combination of severity and priority, which
> is how the Launchpad team say it's supposed to be used.

Thanks for the clarification.

James

Re fullermd's initial <a href="https://bugs.edge.launchpad.net/bzr/+bug/97715/comments/1">comment</a>:

Note that "bzr log should accept more than one file" is filed as bug #211852.

Okay, I guess that answers my question about whether raw HTML syntax works for getting linked text into a comment in the bug tracker :-).

This thread is relevant to this bug:

http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/50472

And this other thread, while not directly relevant to fixing the bug, explains why some developers want the fix:

   http://lists.gnu.org/archive/html/emacs-devel/2008-12/threads.html#00326

Regarding a potential workaround, see this comment:

https://bugs.edge.launchpad.net/bzr/+bug/246891/comments/8

A branch implementing this is now available for testing. See https://code.launchpad.net/~ian-clatworthy/bzr/log-dir. It needs more tests added before I can submit it for review but I believe/hope/pray that's it basically working. Please try it out and let me know if you find any bugs.

Ian Clatworthy <email address hidden> writes:
> A branch implementing this is now available for testing. See
> https://code.launchpad.net/~ian-clatworthy/bzr/log-dir. It needs more
> tests added before I can submit it for review but I believe/hope/pray
> that's it basically working. Please try it out and let me know if you
> find any bugs.

*kiss* :-)

I will test it. Thank you.

Some results:

[I just realized that everything below is with 1.9 format, because that's what the repository I'm testing uses. I should retry with --1.12-preview, right? Would that make a big difference?]

I'm using the Emacs repository for testing. Using bzr built from your branch above, I ran

  $ bzr branch bzr://bzr.notengoamigos.org/emacs-merges-ce/master/
  $ cd master
  ### lisp/ is a subdir with lots of changes under it, let's try that:
  $ time bzr log lisp > lisp-log.out
  ### wait... wait... wait... feels like long time... ###

Hmmm. I opened up lisp-log.out and looked at the tail of the file. It is not hung -- new changes do appear -- but it's going pretty slowly. After about eighteen minutes, the end of the file has this change:

   ------------------------------------------------------------
   revno: 89414
   committer: Jay Belanger <email address hidden>
   timestamp: Sun 2008-07-13 05:42:31 +0000
   message:
     *** empty log message ***
   ------------------------------------------------------------

So it's only in the middle of 2008 (Emacs history go back to 1985, with about 94000 revisions).

I killed it and tried again, this time with -v so I could easily verify that it was only getting changes that affected something under lisp/. It ran at about the same speed (not surprising, when I think about likely implementation). I killed it after 8 minutes.

As far as correctness goes, it's passing all my tests so far. I have some old 'bzr log -v' for the same tree sitting around. It only goes to about November 2002 (I had to kill the process eventually), but checking those two ranges against each other in the old and new logs doesn't raise any problems. They're different, obviously, since the second one was on a subdir, but they're different in the expected ways.

I also tried plain 'bzr log -v' with your branch bzr. It seems to be running at about the same speed as 'bzr log SUBDIR' and 'bzr log -v SUBDIR'. I can't tell yet if it's any faster than it used to be.

On Thu, 2009-02-05 at 22:26 +0000, Karl Fogel wrote:
> Some results:
>
> [I just realized that everything below is with 1.9 format, because
> that's what the repository I'm testing uses. I should retry with
> --1.12-preview, right? Would that make a big difference?]

No difference at all; it only changes the working tree and will not
affect log or push/pull times.

-Rob

Karl Fogel wrote:
> Some results:
>
> [I just realized that everything below is with 1.9 format, because
> that's what the repository I'm testing uses. I should retry with
> --1.12-preview, right? Would that make a big difference?]

1.12-preview will make no difference at all. That format is a small
tweak to what the working tree permits. The speed issues here are
related to the repository format.

> ### lisp/ is a subdir with lots of changes under it, let's try that:
> $ time bzr log lisp > lisp-log.out
> ### wait... wait... wait... feels like long time... ###
>
> Hmmm. I opened up lisp-log.out and looked at the tail of the file. It
> is not hung -- new changes do appear -- but it's going pretty slowly.

Right. It's going as fast I can make it until the next repository format
lands in coming months. As you suspected, there's no difference in
performance between "log -v DIR" and "log DIR" as I need the partial
deltas anyhow to determine whether to include a revision or not. OTOH,
"log -v DIR" will be faster than "log -v --all-files DIR" and that
should be faster than "log -v".

> As far as correctness goes, it's passing all my tests so far. I have
> some old 'bzr log -v' for the same tree sitting around. It only goes to
> about November 2002 (I had to kill the process eventually), but checking
> those two ranges against each other in the old and new logs doesn't
> raise any problems. They're different, obviously, since the second one
> was on a subdir, but they're different in the expected ways.

Thanks for the testing. Sounds like it's working, just not fast enough.
That's the best I can offer right now, sorry.

Ian C.

Ian Clatworthy <email address hidden> writes:
>> As far as correctness goes, it's passing all my tests so far. I have
>> some old 'bzr log -v' for the same tree sitting around. It only goes to
>> about November 2002 (I had to kill the process eventually), but checking
>> those two ranges against each other in the old and new logs doesn't
>> raise any problems. They're different, obviously, since the second one
>> was on a subdir, but they're different in the expected ways.
>
> Thanks for the testing. Sounds like it's working, just not fast enough.
> That's the best I can offer right now, sorry.

Hey, working at all is still progress. When the improved repository
format comes out we'll hopefully get the speed too.

If the remaining performances issues are really a subcase of bug
#246891, then this bug can be closed, right?

When the new (split-inventory) format lands, some tweaks will still be required to take advantage of the fact that the lower level data is more or less what we want. Otherwise, we'll convert a delta into inventories and then work out the delta from them. :-)