Re: patch vs. overwrite in bzr

[Bastien]

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