emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#8025: 24.0.50; vc-bzr does not perform initial commit


From: Christoph Scholtes
Subject: Re: bug#8025: 24.0.50; vc-bzr does not perform initial commit
Date: Tue, 01 Mar 2011 09:19:47 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

I looked into this issue yesterday and I narrowed it down to the following function in `vc-bzr.el': `vc-bzr-state-heuristic'.

Apparently, when there is a bare repo and when trying to register the first file, the heuristic function, which parses the dir-state file, fails and reports the file unregistered all the time, even after it has been registered. It starts working correctly when you register the file and commit the file externally. I have not been able to figure out why the parsing fails.

It also works when bypassing the heuristic function and calling `vc-bzr-state' all the time.

I am wondering whether the heuristic function should be removed/simplified.

There is a comment at the beginning of the function:
  ;; `bzr status' was excruciatingly slow with large histories and
  ;; pending merges, so try to avoid using it until they fix their
  ;; performance problems.
  ;; This function tries first to parse Bzr internal file
  ;; `checkout/dirstate', but it may fail if Bzr internal file format
  ;; has changed.  As a safeguard, the `checkout/dirstate' file is
  ;; only parsed if it contains the string `#bazaar dirstate flat
  ;; format 3' in the first line.

`excruciatingly slow' does not mean anything to me. Is this still an issue with the latest version of bzr? If we can be reasonably sure it is not, we should just have it call `vc-bzr-state' all the time and eliminate this fragile construct of parsing the file manually. I think if bzr has a performance issue bzr should be fixed not emacs.

So, my question is: do I spent the time trying to fix this issue or can we agree to make bzr work like any of the other backends and call its native stat function all the time?

Also, does anybody have actual performance numbers that would support keeping this function around?

Christoph



reply via email to

[Prev in Thread] Current Thread [Next in Thread]