[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: patch vs. overwrite in bzr
From: |
Bastien |
Subject: |
Re: patch vs. overwrite in bzr |
Date: |
Fri, 06 Apr 2012 12:20:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: Bastien <address@hidden>
>> Cc: address@hidden, address@hidden, address@hidden
>> Date: Fri, 06 Apr 2012 11:20:18 +0200
>>
>> Eli Zaretskii <address@hidden> writes:
>>
>> >> From: Bastien <address@hidden>
>> >> Cc: Stefan Monnier <address@hidden>, address@hidden, address@hidden
>> >> Date: Fri, 06 Apr 2012 10:29:13 +0200
>> >>
>> >> Regular Org testers don't want to rebuild Emacs each time they have
>> >> to test a new feature in Org.
>> >
>> > Why would they need to do that? Org is not preloaded into Emacs, so
>> > all you need is compile the new Org files and perhaps restart the
>> > Emacs session, but not rebuild Emacs.
>>
>> Right. But there are other problems.
>>
>> - Updating to the latest Org via `bzr update' would take longer compared
>> to the current `git pull' (several factors here...)
>
> Like what? And how much faster is "faster"?
Like "significantly for my own usage".
Check this source for a comparison:
http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#high-storage-efficiency-and-speed
Git might be slower on Windows, though.
I think nobody really disagree with git being faster.
> I believe this is just the general git-preference issue, which has
> nothing to do with "faster".
Sorry to disagree. And it's a key factor, especially for small projects
that you want to follow/help occasionally.
>> - Some people don't have access to their Emacs installation (at work,
>> for example) and still want the latest Org.
>
> Well, that's what site-lisp and/or load-path are for, right? That's
> how those users install Org right now anyway, I believe. They can
> continue doing that if Org were to be maintained as part of the Emacs
> repository.
You suggest Org testers should clone Emacs and add the relevant
load-path in their setup, just to be able to test Org? Mhh.. doesn't
look really sexy to me.
>> And surely more. In any case, I'm all in favor of having the most
>> recent Org in Emacs trunk regularily, but migrating the development
>> of Org from the separate git repo to Emacs bzr repo is a no-go.
>
> I understand, and I think this is the _only_ real issue involved.
Since I agree this is the main one, I won't argue about the other
issues anyway :) And I guess we all have too much to do to argue
on such things.
Looking forward,
--
Bastien
- Re: patch vs. overwrite in bzr, (continued)
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/04
- Re: patch vs. overwrite in bzr, Stefan Monnier, 2012/04/05
- Re: patch vs. overwrite in bzr, Lars Magne Ingebrigtsen, 2012/04/05
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/05
- Re: patch vs. overwrite in bzr, Ted Zlatanov, 2012/04/05
- Re: patch vs. overwrite in bzr, Richard Stallman, 2012/04/06
- Re: patch vs. overwrite in bzr, Bastien, 2012/04/06
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/06
- Re: patch vs. overwrite in bzr, Bastien, 2012/04/06
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/06
- Re: patch vs. overwrite in bzr,
Bastien <=
- Re: patch vs. overwrite in bzr, chad, 2012/04/06
- Re: patch vs. overwrite in bzr, joakim, 2012/04/06
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/06
- Re: patch vs. overwrite in bzr, Óscar Fuentes, 2012/04/06
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/07
- Re: patch vs. overwrite in bzr, Óscar Fuentes, 2012/04/07
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/07
- Re: patch vs. overwrite in bzr, Óscar Fuentes, 2012/04/07
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/07
- Re: patch vs. overwrite in bzr, Óscar Fuentes, 2012/04/07