Repository conversion

Repository conversion

[Eric S. Raymond]

Is there anything like a schedule?

Every technical blocking issue known to me has been solved.

My repo build procedure is completely canned at this point.  I plan to
do another repo build tonight (they take about 8 hours). Will probably
be able to show another trial repo tomorrow.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
        -- Mike Royko, Chicago Tribune

Re: Repository conversion

[Karl Fogel]

esr@thyrsus.com (Eric S. Raymond) writes:
>Is there anything like a schedule?
>
>Every technical blocking issue known to me has been solved.
>
>My repo build procedure is completely canned at this point.  I plan to
>do another repo build tonight (they take about 8 hours). Will probably
>be able to show another trial repo tomorrow.

I guess Yidong or Stefan (?) should say the schedule, but +1 here.  I'm
looking forward to the switchover.  Thanks for doing the heavy lifting,
Eric.

Re: Repository conversion

[Kelvin White]

On Wed, Sep 10, 2014 at 12:41 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> esr@thyrsus.com (Eric S. Raymond) writes:
>>Is there anything like a schedule?
>>
>>Every technical blocking issue known to me has been solved.
>>
>>My repo build procedure is completely canned at this point.  I plan to
>>do another repo build tonight (they take about 8 hours). Will probably
>>be able to show another trial repo tomorrow.
>
> I guess Yidong or Stefan (?) should say the schedule, but +1 here.  I'm
> looking forward to the switchover.  Thanks for doing the heavy lifting,
> Eric.

I am also looking forward to it, Thanks a lot Eric :)

Re: Repository conversion

[Paul Eggert]

As I understand it, the only thing blocking the repo conversion is that 
we wanted to wait until after the next Emacs release.  I hope we have a 
new release sooner rather than later, but I don't think there's a formal 
schedule for it.

If the next release won't happen for quite a while, I suggest doing the 
repo conversion now.  In the ordinary course of development I am 
significantly delayed several times a day by bzr.  With the Emacs source 
tree a trivial 'bzr merge' (just two files, about 30 lines changed, no 
conflicts, both source trees recently visited) takes over 15 seconds on 
my desktop.  The same thing with 'git' would be so fast I wouldn't notice.

Re: Repository conversion

[Glenn Morris]

Eric S. Raymond wrote:

> Every technical blocking issue known to me has been solved.

Is there a list somewhere of what the various issues and their solutions were?
(I'm not interested in the details of the repository conversion,
I mean the other issues that were raised.)

Re: Repository conversion

[Eric S. Raymond]

Glenn Morris <rgm@gnu.org>:
> Eric S. Raymond wrote:
> 
> > Every technical blocking issue known to me has been solved.
> 
> Is there a list somewhere of what the various issues and their solutions were?
> (I'm not interested in the details of the repository conversion,
> I mean the other issues that were raised.)

In the repository for the conversion machinery

git://gitorious.org/emacs-transition/emacs-transition.git

there is a file named transition.txt.  That's what I used to keep track of 
open and resolved issues. If you want to see the resolved ones, git log 
on that file would allow you to reconstruct it pretty easily.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repository conversion

[Glenn Morris]

"Eric S. Raymond" wrote:

> git://gitorious.org/emacs-transition/emacs-transition.git
>
> there is a file named transition.txt.

It contains no mention of a bzrmerge.el replacement, what will replace
bzr --fixes, git being run twice on files being visited. But I'm just
repeating myself here. (For --fixes, I see a brief mention on the wiki
page.)

Re: Repository conversion

[Glenn Morris]

PS for the --fixes replacement, I liked the idea of using notes, as per
http://git-scm.com/blog/2010/08/25/notes.html

  git notes --ref=bugzilla add -m 'bug #15' 0385bcc3
  git log --show-notes=bugzilla