emacs-devel
[Top][All Lists]
Advanced

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

Re: patch vs. overwrite in bzr


From: Eli Zaretskii
Subject: Re: patch vs. overwrite in bzr
Date: Fri, 06 Apr 2012 12:57:40 +0300

> 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"?

I believe this is just the general git-preference issue, which has
nothing to do with "faster".

> - 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.

> 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.



reply via email to

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