* Next pretest, and regressions policy @ 2012-03-22 13:28 Chong Yidong 2012-03-31 10:15 ` Bastien 0 siblings, 1 reply; 85+ messages in thread From: Chong Yidong @ 2012-03-22 13:28 UTC (permalink / raw) To: emacs-devel I plan to make the next pretest on April 1. After this weekend, please commit only fixes for regressions against Emacs 23.4, apart from documentation fixes. If you would like to commit a fix for a non-regression bug, please discuss on emacs-devel first. Thank you. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-03-22 13:28 Next pretest, and regressions policy Chong Yidong @ 2012-03-31 10:15 ` Bastien 2012-04-01 9:55 ` Bastien 0 siblings, 1 reply; 85+ messages in thread From: Bastien @ 2012-03-31 10:15 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel Chong Yidong <cyd@gnu.org> writes: > I plan to make the next pretest on April 1. I released Org 7.8.07, which I will merge into Emacs trunk tomorrow morning. 7.8.07 is a bugfix release against 7.8.03, the current Org version in Emacs. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-03-31 10:15 ` Bastien @ 2012-04-01 9:55 ` Bastien 2012-04-01 12:37 ` =?utf-8?Q?=C3=93scar_Fuentes?= 0 siblings, 1 reply; 85+ messages in thread From: Bastien @ 2012-04-01 9:55 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel Bastien <bzg@gnu.org> writes: > Chong Yidong <cyd@gnu.org> writes: > >> I plan to make the next pretest on April 1. > > I released Org 7.8.07, which I will merge into Emacs trunk > tomorrow morning. Done. I carefully reviewed the ChangeLogs, but if anything looks wrong or suspicious, please let me know. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 9:55 ` Bastien @ 2012-04-01 12:37 ` =?utf-8?Q?=C3=93scar_Fuentes?= 2012-04-01 13:30 ` Stefan Monnier 2012-04-01 20:35 ` Next pretest, and regressions policy Bastien 0 siblings, 2 replies; 85+ messages in thread From: =?utf-8?Q?=C3=93scar_Fuentes?= @ 2012-04-01 12:37 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel Bastien <bzg@gnu.org> writes: >> I released Org 7.8.07, which I will merge into Emacs trunk >> tomorrow morning. > > Done. I carefully reviewed the ChangeLogs, but if anything > looks wrong or suspicious, please let me know. Hello Bastien. At a first glance, there are places where copyright notices and other boilerplate are overwritten with older text. The most glaring case is this: === modified file 'lisp/org/ob-fortran.el' --- a/lisp/org/ob-fortran.el 2012-01-10 06:20:22 +0000 +++ b/lisp/org/ob-fortran.el 2012-04-01 09:49:25 +0000 @@ -1,32 +1,29 @@ ;;; ob-fortran.el --- org-babel functions for fortran -;; Copyright (C) 2011-2012 Free Software Foundation, Inc. +;; Copyright (C) 2011-2012 Sergey Litvinov, Eric Schulte -;; Authors: Sergey Litvinov -;; Eric Schulte +;; Authors: Sergey Litvinov (based on ob-C.el by Eric Schulte), Eric Schulte ;; Keywords: literate programming, reproducible research, fortran ;; Homepage: http://orgmode.org -;; Version: 7.8.02 - -;; This file is part of GNU Emacs. - -;; GNU Emacs is free software: you can redistribute it and/or modify + +;; This program is free software; you can redistribute it and/or modify All other occurrences of "Copyright" on your commit are an indication of a mistake. I suggest that, before syncing, you obtain a diff from the bzr (or git) emacs repo that contains all changes to org since your last sync, commit the diff onto your org sources and then proceed with the new sync. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 12:37 ` =?utf-8?Q?=C3=93scar_Fuentes?= @ 2012-04-01 13:30 ` Stefan Monnier 2012-04-01 17:09 ` Chong Yidong ` (2 more replies) 2012-04-01 20:35 ` Next pretest, and regressions policy Bastien 1 sibling, 3 replies; 85+ messages in thread From: Stefan Monnier @ 2012-04-01 13:30 UTC (permalink / raw) To: =?utf-8?Q?=C3=93scar_Fuentes?=; +Cc: Bastien, emacs-devel > At a first glance, there are places where copyright notices and other > boilerplate are overwritten with older text. The most glaring case is > this: Once again: please *never ever* overwrite files. Always apply a patch instead. Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 13:30 ` Stefan Monnier @ 2012-04-01 17:09 ` Chong Yidong 2012-04-01 20:32 ` Bastien 2012-04-01 20:32 ` Bastien 2012-04-03 8:20 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Roland Winkler 2 siblings, 1 reply; 85+ messages in thread From: Chong Yidong @ 2012-04-01 17:09 UTC (permalink / raw) To: Bastien; +Cc: =?utf-8?Q?=C3=93scar_Fuentes?=, Stefan Monnier, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> At a first glance, there are places where copyright notices and other >> boilerplate are overwritten with older text. The most glaring case is >> this: > > Once again: please *never ever* overwrite files. Always apply > a patch instead. Please fix this ASAP, Bastien. I will wait for confirmation from you that this is fixed before making the pretest. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 17:09 ` Chong Yidong @ 2012-04-01 20:32 ` Bastien 2012-04-02 4:12 ` Chong Yidong 0 siblings, 1 reply; 85+ messages in thread From: Bastien @ 2012-04-01 20:32 UTC (permalink / raw) To: Chong Yidong; +Cc: =?utf-8?Q?=C3=93scar_Fuentes?=, Stefan Monnier, emacs-devel Chong Yidong <cyd@gnu.org> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >>> At a first glance, there are places where copyright notices and other >>> boilerplate are overwritten with older text. The most glaring case is >>> this: >> >> Once again: please *never ever* overwrite files. Always apply >> a patch instead. > > Please fix this ASAP, Bastien. I will wait for confirmation from you > that this is fixed before making the pretest. This is fixed now. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 20:32 ` Bastien @ 2012-04-02 4:12 ` Chong Yidong 0 siblings, 0 replies; 85+ messages in thread From: Chong Yidong @ 2012-04-02 4:12 UTC (permalink / raw) To: Bastien; +Cc: =?utf-8?Q?=C3=93scar_Fuentes?=, Stefan Monnier, emacs-devel Bastien <bzg@gnu.org> writes: >>> Once again: please *never ever* overwrite files. Always apply >>> a patch instead. >> >> Please fix this ASAP, Bastien. I will wait for confirmation from you >> that this is fixed before making the pretest. > > This is fixed now. Thanks. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 13:30 ` Stefan Monnier 2012-04-01 17:09 ` Chong Yidong @ 2012-04-01 20:32 ` Bastien 2012-04-03 8:20 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Roland Winkler 2 siblings, 0 replies; 85+ messages in thread From: Bastien @ 2012-04-01 20:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: =?utf-8?Q?=C3=93scar_Fuentes?=, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> At a first glance, there are places where copyright notices and other >> boilerplate are overwritten with older text. The most glaring case is >> this: > > Once again: please *never ever* overwrite files. Always apply > a patch instead. Mhh.. okay. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-01 13:30 ` Stefan Monnier 2012-04-01 17:09 ` Chong Yidong 2012-04-01 20:32 ` Bastien @ 2012-04-03 8:20 ` Roland Winkler 2012-04-03 12:36 ` Óscar Fuentes 2 siblings, 1 reply; 85+ messages in thread From: Roland Winkler @ 2012-04-03 8:20 UTC (permalink / raw) To: emacs-devel On Sun, Apr 01 2012, Stefan Monnier wrote: >> At a first glance, there are places where copyright notices and other >> boilerplate are overwritten with older text. The most glaring case is >> this: > > Once again: please *never ever* overwrite files. Always apply > a patch instead. I read this at several occassions. -- I am not an expert with bzr and I was wondering whether "never overwriting files" translates into a recommended work flow with bzr. Most of my knowledge about using bzr with emacs development stems from http://www.emacswiki.org/emacs/BzrForEmacsDevs where I couldn't find anything about this. Thanks, Roland ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-03 8:20 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Roland Winkler @ 2012-04-03 12:36 ` Óscar Fuentes 2012-04-03 13:42 ` Bastien 0 siblings, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2012-04-03 12:36 UTC (permalink / raw) To: emacs-devel Roland Winkler <winkler@gnu.org> writes: > On Sun, Apr 01 2012, Stefan Monnier wrote: >>> At a first glance, there are places where copyright notices and other >>> boilerplate are overwritten with older text. The most glaring case is >>> this: >> >> Once again: please *never ever* overwrite files. Always apply >> a patch instead. > > I read this at several occassions. -- I am not an expert with bzr and I > was wondering whether "never overwriting files" translates into a > recommended work flow with bzr. Stefan's advice has nothing to do with bzr. It is about not blindly overwriting changes made on the emacs repo with the new version of the externally-maintained package (`Org' is in this case.) Applying a patch gives a lot more opportunities for noticing conflicts (suppossing that the hacker cares to examine the output of the patch command, that is.) [snip] ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-03 12:36 ` Óscar Fuentes @ 2012-04-03 13:42 ` Bastien 2012-04-03 15:02 ` patch vs. overwrite in bzr =?utf-8?Q?=C3=93scar_Fuentes?= ` (4 more replies) 0 siblings, 5 replies; 85+ messages in thread From: Bastien @ 2012-04-03 13:42 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Roland Winkler <winkler@gnu.org> writes: > >> On Sun, Apr 01 2012, Stefan Monnier wrote: >>>> At a first glance, there are places where copyright notices and other >>>> boilerplate are overwritten with older text. The most glaring case is >>>> this: >>> >>> Once again: please *never ever* overwrite files. Always apply >>> a patch instead. >> >> I read this at several occassions. -- I am not an expert with bzr and I >> was wondering whether "never overwriting files" translates into a >> recommended work flow with bzr. > > Stefan's advice has nothing to do with bzr. It is about not blindly > overwriting changes made on the emacs repo with the new version of the > externally-maintained package (`Org' is in this case.) Applying a patch > gives a lot more opportunities for noticing conflicts (suppossing that > the hacker cares to examine the output of the patch command, that is.) The problem is: how to create a patch from Org git repo that can be easily applied to Emacs bzr repo. If someone can come up with a workable solution, that'd help me a lot. Oscar, you said: > I suggest that, before syncing, you obtain a diff from the bzr (or git) > emacs repo that contains all changes to org since your last sync, commit > the diff onto your org sources and then proceed with the new sync. Which is theoretically fine... but if someone can actually *test* the suggested workflow, I'm all ears. Thanks! -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 13:42 ` Bastien @ 2012-04-03 15:02 ` =?utf-8?Q?=C3=93scar_Fuentes?= 2012-04-03 15:03 ` David Engster ` (3 subsequent siblings) 4 siblings, 0 replies; 85+ messages in thread From: =?utf-8?Q?=C3=93scar_Fuentes?= @ 2012-04-03 15:02 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel Bastien <bzg@gnu.org> writes: > The problem is: how to create a patch from Org git repo that can be > easily applied to Emacs bzr repo. I don't know how the file structure of Org maps to Emacs' but this should work for obtaining the changes made to `lisp' directory of Org: `git diff COMMIT1 COMMIT2 lisp > changes-in-org-lisp.patch' where COMMIT1 is the range of revisions containing the changes you want to incorporate into Emacs. Then, on the Emacs source tree, cd to lisp/org and patch -p 2 < changes-in-org-lisp.patch Watch for conflicts. Repeat for `doc' and other directories to be synched. Review the changes with `bzr diff' and commit. There should be no conflicts if you previously followed the same procedure but in the Emacs -> Org direction. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 13:42 ` Bastien 2012-04-03 15:02 ` patch vs. overwrite in bzr =?utf-8?Q?=C3=93scar_Fuentes?= @ 2012-04-03 15:03 ` David Engster 2012-04-03 16:31 ` Stefan Monnier 2012-04-03 15:32 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Stefan Monnier ` (2 subsequent siblings) 4 siblings, 1 reply; 85+ messages in thread From: David Engster @ 2012-04-03 15:03 UTC (permalink / raw) To: Bastien; +Cc: Óscar Fuentes, emacs-devel Bastien writes: > Óscar Fuentes <ofv@wanadoo.es> writes: >> Stefan's advice has nothing to do with bzr. It is about not blindly >> overwriting changes made on the emacs repo with the new version of the >> externally-maintained package (`Org' is in this case.) Applying a patch >> gives a lot more opportunities for noticing conflicts (suppossing that >> the hacker cares to examine the output of the patch command, that is.) > > The problem is: how to create a patch from Org git repo that can be > easily applied to Emacs bzr repo. > > If someone can come up with a workable solution, that'd help me a lot. > > Oscar, you said: > >> I suggest that, before syncing, you obtain a diff from the bzr (or git) >> emacs repo that contains all changes to org since your last sync, commit >> the diff onto your org sources and then proceed with the new sync. > > Which is theoretically fine... but if someone can actually *test* the > suggested workflow, I'm all ears. I'm in the process of writing a merge tool cedet-emacs-merge.el ('ceemme') for the upcoming CEDET/Emacs merges. You can find a very rough first revision in our 'newtrunk': http://cedet.bzr.sourceforge.net/bzr/cedet/code/newtrunk/files Now, it clearly cannot be used straight away for org, since we're using bzr and there are some very CEDET specific things in the code when adapting paths and stuff like that, but it might give you an idea how I'm planning to do things. Again: it's very early and I'm not using it in production yet (will happen when Eric has released the current trunk as 1.1). In a nutshell: It's more or less a GUI to do cherry picking with bzr and marking commits as 'applied', 'ignored' etc. and saving that state in the repository between sessions. In the end it will work in both directions, but currently I'm concentrating on the Emacs -> CEDET, since this will be the first thing to do next. Also, for the other direction we will probably use a dedicated branch like 'for-emacs' or something like that and not directly push into Emacs. If you or someone else would be interested into making this into a more generic cross-project merge tool - I am all ears. However, I could also imagine that there might be some git-trickery using submodules or whatever which allows a more elegant workflow. -David ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 15:03 ` David Engster @ 2012-04-03 16:31 ` Stefan Monnier 2012-04-03 17:40 ` Michael Albinus 0 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2012-04-03 16:31 UTC (permalink / raw) To: Bastien; +Cc: Óscar Fuentes, emacs-devel > In a nutshell: It's more or less a GUI to do cherry picking with bzr and > marking commits as 'applied', 'ignored' etc. and saving that state in > the repository between sessions. In the end it will work in both > directions, but currently I'm concentrating on the Emacs -> CEDET, since > this will be the first thing to do next. Also, for the other direction > we will probably use a dedicated branch like 'for-emacs' or something > like that and not directly push into Emacs. The Gnus guys also do two-way syncing and have to solve the same problem. A generic tool would be awesome. I think two-way syncing of branches is a major problem with current VCS technology and I'm eagerly awaiting a good generic solution to it. I'm sure I'm not the only one. Even better if it can be run from a cron job (i.e. fully automatic and deals with conflicts somehow (obviously, it can't resolve them, so it needs to store them somewhere, make sure someone will see them and will be able to resolve them, ...)). Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 16:31 ` Stefan Monnier @ 2012-04-03 17:40 ` Michael Albinus 0 siblings, 0 replies; 85+ messages in thread From: Michael Albinus @ 2012-04-03 17:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: Bastien, =?utf-8?Q?=C3=93scar?= Fuentes, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > The Gnus guys also do two-way syncing and have to solve the same > problem. A generic tool would be awesome. 1+. Tramp. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-03 13:42 ` Bastien 2012-04-03 15:02 ` patch vs. overwrite in bzr =?utf-8?Q?=C3=93scar_Fuentes?= 2012-04-03 15:03 ` David Engster @ 2012-04-03 15:32 ` Stefan Monnier 2012-04-03 16:52 ` patch vs. overwrite in bzr Glenn Morris 2012-04-04 17:12 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Eli Zaretskii 2012-04-04 18:01 ` Thierry Volpiatto 4 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2012-04-03 15:32 UTC (permalink / raw) To: Bastien; +Cc: Óscar Fuentes, emacs-devel > The problem is: how to create a patch from Org git repo that can be > easily applied to Emacs bzr repo. Remember somewhere which was the last revision of Org that was sync'd to Emacs, and then create the patch by diffing against that revision. Stefan PS: And after applying the patch, update the place where you remember the last revision sync'd. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 15:32 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Stefan Monnier @ 2012-04-03 16:52 ` Glenn Morris 2012-04-03 20:50 ` Bastien 0 siblings, 1 reply; 85+ messages in thread From: Glenn Morris @ 2012-04-03 16:52 UTC (permalink / raw) To: emacs-devel Stefan Monnier wrote: > Remember somewhere which was the last revision of Org that was sync'd to > Emacs, and then create the patch by diffing against that revision. As was said last time this happened (which is basically every time): http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00648.html ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 16:52 ` patch vs. overwrite in bzr Glenn Morris @ 2012-04-03 20:50 ` Bastien 2012-04-03 21:27 ` Glenn Morris 2012-04-04 0:26 ` Stefan Monnier 0 siblings, 2 replies; 85+ messages in thread From: Bastien @ 2012-04-03 20:50 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel Glenn Morris <rgm@gnu.org> writes: > Stefan Monnier wrote: > >> Remember somewhere which was the last revision of Org that was sync'd to >> Emacs, and then create the patch by diffing against that revision. > > As was said last time this happened (which is basically every time): > > http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00648.html True. I already complained about two things: the lack of mechanism to systematically send commits about a module (org/gnus/tramp) to the maintainer of this module; the lack of visibility for the release schedule. Both problems create additional work. The first one because I need to watch the emacs-diffs mailing list carefully and backport small commits to Org (80% of the last 67 commits in the last 480 days were just useful but trivial commits). To improve the situation we could have 3-4 Emacs hackers directly committing in Org while the maintainer focuses on syncing regularily. The second one because it forces us to maintain a separate branch in Org's repo, the one that corresponds to the current Emacs trunk. I already suggested a possible improvement (not a solution) about this: have a different feature freeze window for modules and for Emacs core, but got 0 answer. Now that I'm thru with complaining, I 100% acknowledge my laziness in setting up a good process for the 2-way sync. But I will. I'll see if it works over time. Finally, I'm curious to know whether you, Juanma and Paul would be willing to commit fixes directly in the "hotfix" branch of Org's git. This is the branch that is sync'ed with Emacs trunk, and committing small fixes there first would remove 90% of the pain. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 20:50 ` Bastien @ 2012-04-03 21:27 ` Glenn Morris 2012-04-04 0:26 ` Stefan Monnier 1 sibling, 0 replies; 85+ messages in thread From: Glenn Morris @ 2012-04-03 21:27 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel Bastien wrote: > Finally, I'm curious to know whether you, Juanma and Paul would be > willing to commit fixes directly in the "hotfix" branch of Org's git. > This is the branch that is sync'ed with Emacs trunk, and committing > small fixes there first would remove 90% of the pain. Thanks for the offer, but speaking for myself, no. I gave up making any changes to Org, other than copyright-related ones. That isn't hard to get right (just pay attention when adding new files that the headers look the same as every other file in Emacs), so anyone can do it, if they care to. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-03 20:50 ` Bastien 2012-04-03 21:27 ` Glenn Morris @ 2012-04-04 0:26 ` Stefan Monnier 2012-04-04 5:45 ` Bastien 2012-04-04 5:51 ` Bastien 1 sibling, 2 replies; 85+ messages in thread From: Stefan Monnier @ 2012-04-04 0:26 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel > I already suggested a possible improvement (not a solution) about > this: have a different feature freeze window for modules and for Emacs > core, but got 0 answer. I may have replied elsewhere. The way I see it, Org should be taken out of `trunk' and instead the Emacs release should include a set of ELPA packages (including Org). > Finally, I'm curious to know whether you, Juanma and Paul would be > willing to commit fixes directly in the "hotfix" branch of Org's git. > This is the branch that is sync'ed with Emacs trunk, and committing > small fixes there first would remove 90% of the pain. If you let people commit to that branch it might become more difficult to use it for the sync. Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 0:26 ` Stefan Monnier @ 2012-04-04 5:45 ` Bastien 2012-04-04 5:51 ` Bastien 1 sibling, 0 replies; 85+ messages in thread From: Bastien @ 2012-04-04 5:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Finally, I'm curious to know whether you, Juanma and Paul would be >> willing to commit fixes directly in the "hotfix" branch of Org's git. >> This is the branch that is sync'ed with Emacs trunk, and committing >> small fixes there first would remove 90% of the pain. > > If you let people commit to that branch it might become more difficult > to use it for the sync. Why? E.g. If Paul committed spelling fixes to the hotfix branch of Org, then merging this branch to Emacs would trigger less merge conflicts. It doesn't remove the need for double-checking and for committing patches instead of overwriting files, but it certainly alleviate the maintainance burden. I must be missing something. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 0:26 ` Stefan Monnier 2012-04-04 5:45 ` Bastien @ 2012-04-04 5:51 ` Bastien 2012-04-04 6:46 ` Michael Albinus 2012-04-04 13:16 ` Stefan Monnier 1 sibling, 2 replies; 85+ messages in thread From: Bastien @ 2012-04-04 5:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I already suggested a possible improvement (not a solution) about >> this: have a different feature freeze window for modules and for Emacs >> core, but got 0 answer. > > I may have replied elsewhere. The way I see it, Org should be taken out > of `trunk' and instead the Emacs release should include a set of ELPA > packages (including Org). If people continue fixing things in ELPA instead of fixing them in Org, we have the same 2-way sync challenge. IMHO this move would just send a signal to Emacs devs "do not try to fix this, it's just an ELPA package" -- which does not so good to me. I'd rather stick to the current situation where I get blamed for my laziness in merging "the proper way", while still having vigilant people like Glenn, Paul, Juanma and others fixing stuff in Org :) After all, Org is in a pretty good shape right now in trunk. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 5:51 ` Bastien @ 2012-04-04 6:46 ` Michael Albinus 2012-04-04 8:35 ` Thierry Volpiatto 2012-04-04 13:16 ` Stefan Monnier 1 sibling, 1 reply; 85+ messages in thread From: Michael Albinus @ 2012-04-04 6:46 UTC (permalink / raw) To: Bastien; +Cc: Stefan Monnier, emacs-devel Bastien <bzg@gnu.org> writes: >> I may have replied elsewhere. The way I see it, Org should be taken out >> of `trunk' and instead the Emacs release should include a set of ELPA >> packages (including Org). > > IMHO this move would just send a signal to Emacs devs "do not try to > fix this, it's just an ELPA package" -- which does not so good to me. I share the same fear that a package residing in the elpa branch could be regarded as second class citizen. OTOH, being an elpa package would require from us (external) package maintainers shorter freeze windows, before a new Emacs release is shipped. New Tramp features are stalled from being synced since June. A similar freeze period was before releasing Emacs 23. And in the Emacs 22 case, the freeze was for about 3 years, if I'm not totally wrong. But maybe I'm just a too pedantic German, following every freeze policy ... Best regards, Michael. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 6:46 ` Michael Albinus @ 2012-04-04 8:35 ` Thierry Volpiatto 2012-04-04 13:20 ` Stefan Monnier 2012-04-04 17:09 ` Eli Zaretskii 0 siblings, 2 replies; 85+ messages in thread From: Thierry Volpiatto @ 2012-04-04 8:35 UTC (permalink / raw) To: emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > Bastien <bzg@gnu.org> writes: > >>> I may have replied elsewhere. The way I see it, Org should be taken out >>> of `trunk' and instead the Emacs release should include a set of ELPA >>> packages (including Org). >> >> IMHO this move would just send a signal to Emacs devs "do not try to >> fix this, it's just an ELPA package" -- which does not so good to me. > > I share the same fear that a package residing in the elpa branch could > be regarded as second class citizen. OTOH, being an elpa package would > require from us (external) package maintainers shorter freeze windows, > before a new Emacs release is shipped. New Tramp features are stalled > from being synced since June. A similar freeze period was before > releasing Emacs 23. > > And in the Emacs 22 case, the freeze was for about 3 years, if I'm not > totally wrong. But maybe I'm just a too pedantic German, following every > freeze policy ... I never understood why Emacs have not a developing branch to continue developing new features during the feature freeze. I think Emacs lost a lot a new features during this process, especially from contributors that send patches; most patches are lost or are unusable after several months of modifications in trunk. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 8:35 ` Thierry Volpiatto @ 2012-04-04 13:20 ` Stefan Monnier 2012-04-04 16:39 ` Jordi Gutiérrez Hermoso 2012-04-04 16:52 ` Paul Eggert 2012-04-04 17:09 ` Eli Zaretskii 1 sibling, 2 replies; 85+ messages in thread From: Stefan Monnier @ 2012-04-04 13:20 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > I never understood why Emacs have not a developing branch to continue > developing new features during the feature freeze. This is because we do not believe we have the manpower to keep two active branches, and that most people would just keep on using the `trunk' rather than help debug the feature-frozen branch. Whether this belief is warranted, I do not know, sadly. I would be open to experiment with the alternative, Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 13:20 ` Stefan Monnier @ 2012-04-04 16:39 ` Jordi Gutiérrez Hermoso 2012-04-04 16:52 ` Paul Eggert 1 sibling, 0 replies; 85+ messages in thread From: Jordi Gutiérrez Hermoso @ 2012-04-04 16:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, Thierry Volpiatto On 4 April 2012 09:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> I never understood why Emacs have not a developing branch to continue >> developing new features during the feature freeze. > > This is because we do not believe we have the manpower to keep two > active branches, and that most people would just keep on using the > `trunk' rather than help debug the feature-frozen branch. > > Whether this belief is warranted, I do not know, sadly. > I would be open to experiment with the alternative, From one gnu to another, I think you should experiment. In Octave, during release time we merge dev to stable, everyone regularly builds stable, RC tarballs get released, people build them and report them, and eventually the grand stable release is made, which is still maintained in a separate stable branch. Meanwhile, dev goes on its merry way, reguarly getting merged from stable, and people who don't care about release schedules keep playing in dev. Octave has a much smaller dev community than Emacs, and it seems to work for us. - Jordi G. H. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 13:20 ` Stefan Monnier 2012-04-04 16:39 ` Jordi Gutiérrez Hermoso @ 2012-04-04 16:52 ` Paul Eggert 1 sibling, 0 replies; 85+ messages in thread From: Paul Eggert @ 2012-04-04 16:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel On 04/04/2012 06:20 AM, Stefan Monnier wrote: > This is because we do not believe we have the manpower to keep two > active branches, and that most people would just keep on using the > `trunk' rather than help debug the feature-frozen branch. As it happens I made a similar point in a lecture in my undergrad software engineering course yesterday, and used Emacs 24 development as the example! Real-world software engineering often differs from textbook assumptions of unlimited development resources. > I would be open to experiment with the alternative, If the trunk were unfrozen, I confess that I'd probably make almost all my changes to the trunk. Debugging is less fun, at least for this volunteer. But the alternative might be a good idea anyway, as it might encourage more contributions overall while maintaining an acceptably low defect rate in the production version. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 8:35 ` Thierry Volpiatto 2012-04-04 13:20 ` Stefan Monnier @ 2012-04-04 17:09 ` Eli Zaretskii 2012-04-04 17:53 ` Thierry Volpiatto 1 sibling, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-04 17:09 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Wed, 04 Apr 2012 10:35:34 +0200 > > I never understood why Emacs have not a developing branch to continue > developing new features during the feature freeze. Read the archives for past discussions of this issue, and you will understand. The reason is insufficient resources. It takes a significant effort to run a pretest, triage the bugs and fix important ones, update the manuals, etc. The extremely small number of core maintainers does not leave resources to overview both the branch and the trunk, as long as there's lots of work on each one of them. People who want this to change should volunteer to do the tasks that are needed to be done for the pretest and release. Then 2 things will happen: (1) there will be more people who can take a responsibility for a release, thus freeing more time for the head maintainers to take care of the trunk; and (2) the number of people who are familiar with Emacs enough to become core maintainers will also grow. > I think Emacs lost a lot a new features during this process, especially > from contributors that send patches; most patches are lost or > are unusable after several months of modifications in trunk. If you use bzr or any other dVCS, you can simply put your changes on a branch or even a shelf, and then when the time comes to push them, you will have much less trouble than you think. Modern VCSes do a very good job at merging. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 17:09 ` Eli Zaretskii @ 2012-04-04 17:53 ` Thierry Volpiatto 2012-04-04 19:07 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Thierry Volpiatto @ 2012-04-04 17:53 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Wed, 04 Apr 2012 10:35:34 +0200 >> >> I never understood why Emacs have not a developing branch to continue >> developing new features during the feature freeze. > > Read the archives for past discussions of this issue, and you will > understand. The reason is insufficient resources. It takes a > significant effort to run a pretest, triage the bugs and fix important > ones, update the manuals, etc. The extremely small number of core > maintainers does not leave resources to overview both the branch and > the trunk, as long as there's lots of work on each one of them. You should not have to overview the dev branch, only the trunk and merge regularly it in the dev branch. You would have only to review the patches before applying to dev branch, but that's what you already do I think. The difference is just that actually you say, yes patch is ok we will apply it after feature freeze. Instead you would just have to apply if ok. > People who want this to change should volunteer to do the tasks that > are needed to be done for the pretest and release. Then 2 things will > happen: (1) there will be more people who can take a responsibility > for a release, thus freeing more time for the head maintainers to take > care of the trunk; and (2) the number of people who are familiar with > Emacs enough to become core maintainers will also grow. > >> I think Emacs lost a lot a new features during this process, especially >> from contributors that send patches; most patches are lost or >> are unusable after several months of modifications in trunk. > > If you use bzr or any other dVCS, you can simply put your changes on a > branch or even a shelf, and then when the time comes to push them, you > will have much less trouble than you think. Modern VCSes do a very > good job at merging. I know this, I use patches that I can pop and push again after pulling last changes upstream. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 17:53 ` Thierry Volpiatto @ 2012-04-04 19:07 ` Eli Zaretskii 2012-04-04 19:38 ` Thierry Volpiatto 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-04 19:07 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Wed, 04 Apr 2012 19:53:53 +0200 > > You should not have to overview the dev branch, only the trunk and merge > regularly it in the dev branch. You would have only to review the > patches before applying to dev branch, but that's what you already do I > think. The difference is just that actually you say, yes patch is ok we > will apply it after feature freeze. Instead you would just have to apply > if ok. Not true. There's a difference between doing a triage and actually considering the patch for inclusion. In addition, "overviewing" means discussing design and implementation for significant contributions. Development is not just patch reviews, at least not in Emacs. > >> I think Emacs lost a lot a new features during this process, especially > >> from contributors that send patches; most patches are lost or > >> are unusable after several months of modifications in trunk. > > > > If you use bzr or any other dVCS, you can simply put your changes on a > > branch or even a shelf, and then when the time comes to push them, you > > will have much less trouble than you think. Modern VCSes do a very > > good job at merging. > I know this, I use patches that I can pop and push again after pulling > last changes upstream. Then why do you present patch-rot as a significant factor? It isn't. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 19:07 ` Eli Zaretskii @ 2012-04-04 19:38 ` Thierry Volpiatto 2012-04-04 20:12 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Thierry Volpiatto @ 2012-04-04 19:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Wed, 04 Apr 2012 19:53:53 +0200 >> >> You should not have to overview the dev branch, only the trunk and merge >> regularly it in the dev branch. You would have only to review the >> patches before applying to dev branch, but that's what you already do I >> think. The difference is just that actually you say, yes patch is ok we >> will apply it after feature freeze. Instead you would just have to apply >> if ok. > > Not true. There's a difference between doing a triage and actually > considering the patch for inclusion. In addition, "overviewing" means > discussing design and implementation for significant contributions. > Development is not just patch reviews, at least not in Emacs. You are already doing this, so it is not extra work. >> >> I think Emacs lost a lot a new features during this process, especially >> >> from contributors that send patches; most patches are lost or >> >> are unusable after several months of modifications in trunk. >> > >> > If you use bzr or any other dVCS, you can simply put your changes on a >> > branch or even a shelf, and then when the time comes to push them, you >> > will have much less trouble than you think. Modern VCSes do a very >> > good job at merging. >> I know this, I use patches that I can pop and push again after pulling >> last changes upstream. > > Then why do you present patch-rot as a significant factor? Most people don't want to do this and just do not contribute, so you lose many potentials contributors. > It isn't. It is actually not easy to contribute to Emacs. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 19:38 ` Thierry Volpiatto @ 2012-04-04 20:12 ` Eli Zaretskii 0 siblings, 0 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-04 20:12 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: emacs-devel@gnu.org > Date: Wed, 04 Apr 2012 21:38:39 +0200 > > > Not true. There's a difference between doing a triage and actually > > considering the patch for inclusion. In addition, "overviewing" means > > discussing design and implementation for significant contributions. > > Development is not just patch reviews, at least not in Emacs. > You are already doing this Yes, but not on both branches simultaneously. > Most people don't want to do this and just do not contribute, so you > lose many potentials contributors. I sincerely doubt that. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 5:51 ` Bastien 2012-04-04 6:46 ` Michael Albinus @ 2012-04-04 13:16 ` Stefan Monnier 2012-04-04 17:01 ` Eli Zaretskii 1 sibling, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2012-04-04 13:16 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel >>> I already suggested a possible improvement (not a solution) about >>> this: have a different feature freeze window for modules and for Emacs >>> core, but got 0 answer. >> I may have replied elsewhere. The way I see it, Org should be taken out >> of `trunk' and instead the Emacs release should include a set of ELPA >> packages (including Org). > If people continue fixing things in ELPA instead of fixing them in Org, > we have the same 2-way sync challenge. Yes, 2-way syncin is another issue, one that we need to solve rather than get rid of. > IMHO this move would just send a signal to Emacs devs "do not try to > fix this, it's just an ELPA package" -- which does not so good to me. I'd like the `elpa' branch to become more integrated in Emacs so more developers contribute to it just like they would with bundled packages. We're not there yet, tho, obviously. Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 13:16 ` Stefan Monnier @ 2012-04-04 17:01 ` Eli Zaretskii 2012-04-04 18:07 ` Stefan Monnier 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-04 17:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: bzg, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Wed, 04 Apr 2012 09:16:46 -0400 > Cc: emacs-devel@gnu.org > > Yes, 2-way syncin is another issue, one that we need to solve rather > than get rid of. If someone could describe the use cases and the requirements and post that to the bzr mailing list, perhaps we could get some good advice there, or maybe some useful plugins. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 17:01 ` Eli Zaretskii @ 2012-04-04 18:07 ` Stefan Monnier 2012-04-04 19:11 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2012-04-04 18:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bzg, emacs-devel >> Yes, 2-way syncin is another issue, one that we need to solve rather >> than get rid of. > If someone could describe the use cases and the requirements and post > that to the bzr mailing list, perhaps we could get some good advice > there, or maybe some useful plugins. Last time I posted about it (several years ago), it didn't elicit much reaction. IIUC it's just difficult to do it "right" because it's largely incompatible with the way metadata/history is kept. The best you can get is good support for two-way sync between identical branches (which is what we all use, where one of the branch is local to our machine and the other is on bzr.sv.gnu.org), but as soon as the two branches are supposed to be different the model breaks down. The problem is similar to cherry-picking, but reversed: you want to be able to get all changes except for a few negative-cherrypicks. E.g, "pull/merge from the Org branch all changes except for those few ones we don't want" (and inversely, they want to "pull from the Emacs branch, except for the file-renamings they did to adapt to their directory layout"). Since the currently supported metadata can't be used, the solution ends up having to be "manual" and can probably work equally well for most VCS. E.g. keep "tags" on both branches that record the last sync, and when a new sync is attempted, get the diff since last sync on each branch (using the tags), apply the patch to the other branch, commit and update the tags. Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 18:07 ` Stefan Monnier @ 2012-04-04 19:11 ` Eli Zaretskii 2012-04-04 20:11 ` David Engster 2012-04-04 22:06 ` Stefan Monnier 0 siblings, 2 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-04 19:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: bzg, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: bzg@gnu.org, emacs-devel@gnu.org > Date: Wed, 04 Apr 2012 14:07:25 -0400 > > IIUC it's just difficult to do it "right" because it's largely > incompatible with the way metadata/history is kept. The best you can > get is good support for two-way sync between identical branches (which is > what we all use, where one of the branch is local to our machine and > the other is on bzr.sv.gnu.org), but as soon as the two branches are > supposed to be different the model breaks down. > > The problem is similar to cherry-picking, but reversed: you want to be > able to get all changes except for a few negative-cherrypicks. E.g, > "pull/merge from the Org branch all changes except for those few ones we > don't want" (and inversely, they want to "pull from the Emacs branch, > except for the file-renamings they did to adapt to their directory > layout"). Would the problem be solved if such cherry-picking weren't needed? That is, if the branches were exactly identical, but kept in two different VCSes? If this would solve the problem, then that's what I'd suggest doing. After all, all those differences sound very minor; e.g., why not rename the files as the other guy does? > Since the currently supported metadata can't be used, the solution ends > up having to be "manual" and can probably work equally well for most > VCS. E.g. keep "tags" on both branches that record the last sync, and > when a new sync is attempted, get the diff since last sync on each > branch (using the tags), apply the patch to the other branch, commit and > update the tags. Did anyone consider using bzr-git as part of this? It doesn't yet support pushing to a git repo, but it does support "dpush", which could be good enough. And, of course, pulling from a git repository is fully supported. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 19:11 ` Eli Zaretskii @ 2012-04-04 20:11 ` David Engster 2012-04-04 22:06 ` Stefan Monnier 1 sibling, 0 replies; 85+ messages in thread From: David Engster @ 2012-04-04 20:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bzg, Stefan Monnier, emacs-devel Eli Zaretskii writes: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> The problem is similar to cherry-picking, but reversed: you want to be >> able to get all changes except for a few negative-cherrypicks. E.g, >> "pull/merge from the Org branch all changes except for those few ones we >> don't want" (and inversely, they want to "pull from the Emacs branch, >> except for the file-renamings they did to adapt to their directory >> layout"). > > Would the problem be solved if such cherry-picking weren't needed? > That is, if the branches were exactly identical, but kept in two > different VCSes? If this would solve the problem, then that's what > I'd suggest doing. After all, all those differences sound very minor; > e.g., why not rename the files as the other guy does? At least for CEDET, I can surely tell that we won't get fully identical branches, at least not in the foreseeable future. This is mainly due to - compatibility code we keep for older Emacs versions (we will drop Emacs22 support for our new development branch, but there are still things like cedet-called-interactively-p for Emacs 23.1), - features that currently depend on defadvice or other hacks, but that are very useful for hacking on CEDET (generating properly linked help buffers for EIEIO methods and classes, for instance), - minor packages which are not needed or wanted in Emacs proper (like COGRE), - things we don't have papers for and are in our contrib directory, - EIEIO is part of CEDET but not in lisp/cedet but in lisp/emacs-lisp (a similar problem exists with Speedbar, but that is in Emacs for quite some time now and most development happens there anyway). It's not as bad as it sounds; most of the differences are minor or are at least well separated, but still - you need to cherry-pick commits. -David ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 19:11 ` Eli Zaretskii 2012-04-04 20:11 ` David Engster @ 2012-04-04 22:06 ` Stefan Monnier 2012-04-05 3:09 ` Eli Zaretskii 1 sibling, 1 reply; 85+ messages in thread From: Stefan Monnier @ 2012-04-04 22:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bzg, emacs-devel > Would the problem be solved if such cherry-picking weren't needed? To a large extent, yes, but the cases we're talking about can't do that (which is why we're talking about that). > That is, if the branches were exactly identical, but kept in two > different VCSes? If this would solve the problem, then that's what > I'd suggest doing. After all, all those differences sound very minor; > e.g., why not rename the files as the other guy does? The `emacs' branch includes tons of other things that aren't in the `org' branch for obvious reasons. > Did anyone consider using bzr-git as part of this? I started using it for some `elpa' packages, yes. Using a different VCS is not the problem: differences between the branches's contents is the problem. Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-04 22:06 ` Stefan Monnier @ 2012-04-05 3:09 ` Eli Zaretskii 2012-04-05 13:22 ` Stefan Monnier 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-05 3:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: bzg, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: bzg@gnu.org, emacs-devel@gnu.org > Date: Wed, 04 Apr 2012 18:06:19 -0400 > > > Would the problem be solved if such cherry-picking weren't needed? > > To a large extent, yes, but the cases we're talking about can't do that > (which is why we're talking about that). If this is the primary reason for problems, then in my experience this is the first problem to tackle. Whatever the issues are that cause the branches to be different, they should be regarded as secondary, and solutions found for them that let the branches become not different. > > That is, if the branches were exactly identical, but kept in two > > different VCSes? If this would solve the problem, then that's what > > I'd suggest doing. After all, all those differences sound very minor; > > e.g., why not rename the files as the other guy does? > > The `emacs' branch includes tons of other things that aren't in the > `org' branch for obvious reasons. Why should Org maintainers care about things they don't need? Let them be there, they will do no harm at all. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-05 3:09 ` Eli Zaretskii @ 2012-04-05 13:22 ` Stefan Monnier 2012-04-05 15:24 ` Lars Magne Ingebrigtsen 2012-04-06 7:13 ` Richard Stallman 0 siblings, 2 replies; 85+ messages in thread From: Stefan Monnier @ 2012-04-05 13:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bzg, emacs-devel >> The `emacs' branch includes tons of other things that aren't in the >> `org' branch for obvious reasons. > Why should Org maintainers care about things they don't need? Let > them be there, they will do no harm at all. That amounts to using the Emacs repository is the canonical repository for Gnus, ERC, CEDET, MH-E, Org, ... But they don't want to do that, often for good reasons (legal, practical, ...). Stefan ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-05 13:22 ` Stefan Monnier @ 2012-04-05 15:24 ` Lars Magne Ingebrigtsen 2012-04-05 15:57 ` Eli Zaretskii 2012-04-05 17:10 ` Ted Zlatanov 2012-04-06 7:13 ` Richard Stallman 1 sibling, 2 replies; 85+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-04-05 15:24 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > That amounts to using the Emacs repository is the canonical repository > for Gnus, ERC, CEDET, MH-E, Org, ... > But they don't want to do that, often for good reasons (legal, > practical, ...). I would guess that the main practical reason for having the external repositories is the long feature freeze that happens in Emacs development. If Emacs shifted to a "continuous development" model (with branches being forked off for stabilisation now and then), that might change ... stuff. That might not be practical, though, as previously pointed out. Virtually all the developers would "live" in the trunk version of Emacs, so the forked-off stable version would get less love and testing. I don't know. Would it be worth trying to shifting to that model after Emacs 24.1? Preferably with more frequent releases, too. :-) The other practical consideration, though, is that several (some? all?) of the packages mentioned also contains code not relevant for the current Emacs -- compatibility stuff, XEmacs stuff, etc. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-05 15:24 ` Lars Magne Ingebrigtsen @ 2012-04-05 15:57 ` Eli Zaretskii 2012-04-05 17:10 ` Ted Zlatanov 1 sibling, 0 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-05 15:57 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: emacs-devel > From: Lars Magne Ingebrigtsen <larsi@gnus.org> > Date: Thu, 05 Apr 2012 17:24:37 +0200 > > If Emacs shifted to a "continuous development" model (with branches > being forked off for stabilisation now and then), that might change > ... stuff. That might not be practical, though, as previously pointed > out. Virtually all the developers would "live" in the trunk version of > Emacs, so the forked-off stable version would get less love and testing. > > I don't know. Would it be worth trying to shifting to that model after > Emacs 24.1? We could try, but I doubt it will work. For it to work, we need enough people on board to continuously take care of all the important parts of the package (including the documentation and other mundane tasks). What happens now is that the same few need to do all of it, which precludes the model you hope for. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-05 15:24 ` Lars Magne Ingebrigtsen 2012-04-05 15:57 ` Eli Zaretskii @ 2012-04-05 17:10 ` Ted Zlatanov 1 sibling, 0 replies; 85+ messages in thread From: Ted Zlatanov @ 2012-04-05 17:10 UTC (permalink / raw) To: emacs-devel On Thu, 05 Apr 2012 17:24:37 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Stefan Monnier <monnier@iro.umontreal.ca> writes: >> That amounts to using the Emacs repository is the canonical repository >> for Gnus, ERC, CEDET, MH-E, Org, ... >> But they don't want to do that, often for good reasons (legal, >> practical, ...). LMI> I would guess that the main practical reason for having the external LMI> repositories is the long feature freeze that happens in Emacs LMI> development. I would be very unhappy if Gnus switched from Git to Bazaar, and I believe many Gnus and other packages' developers feel the same way. For me, at least, it's a bigger issue than the feature freezes or the compatibility code. Ted ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-05 13:22 ` Stefan Monnier 2012-04-05 15:24 ` Lars Magne Ingebrigtsen @ 2012-04-06 7:13 ` Richard Stallman 2012-04-06 8:29 ` Bastien 2012-04-06 8:43 ` Eli Zaretskii 1 sibling, 2 replies; 85+ messages in thread From: Richard Stallman @ 2012-04-06 7:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: bzg, eliz, emacs-devel That amounts to using the Emacs repository is the canonical repository for Gnus, ERC, CEDET, MH-E, Org, ... But they don't want to do that, often for good reasons (legal, practical, ...). If there is a legal reason for this, doesn't that imply a problem of some kind already exists? We need to find out what the claimed legal reasons are, and think about whether they indicate legal problems for Emacs development. As for practical reasons, doesn't the flexibility of a DVCS make them go away? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 7:13 ` Richard Stallman @ 2012-04-06 8:29 ` Bastien 2012-04-06 8:40 ` Eli Zaretskii 2012-04-07 0:17 ` Richard Stallman 2012-04-06 8:43 ` Eli Zaretskii 1 sibling, 2 replies; 85+ messages in thread From: Bastien @ 2012-04-06 8:29 UTC (permalink / raw) To: rms; +Cc: eliz, Stefan Monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > That amounts to using the Emacs repository is the canonical repository > for Gnus, ERC, CEDET, MH-E, Org, ... > But they don't want to do that, often for good reasons (legal, > practical, ...). As I see it, the main reason for Org to use a separate repository is to gather an active community around a central place. Regular Org testers don't want to rebuild Emacs each time they have to test a new feature in Org. The second main reason is completely subjective: I prefer git over bzr and I want to maintain Org using git. > If there is a legal reason for this, doesn't that imply a problem of > some kind already exists? We need to find out what the claimed legal > reasons are, and think about whether they indicate legal problems for > Emacs development. There is no legal reason for not using the Emacs repository as the canonical repository for Org. Just a practical one: doing so would force us to maintain the canonical Org repository in Emacs *and* another repository for things that are useful to Org and that cannot be part of Emacs. > As for practical reasons, doesn't the flexibility of a DVCS > make them go away? Above legal (unknown) reasons, and above practical reasons, there is this community-based argument I stated above, which is IMHO the most important. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 8:29 ` Bastien @ 2012-04-06 8:40 ` Eli Zaretskii 2012-04-06 9:20 ` Bastien 2012-04-06 16:17 ` Christophe Poncy 2012-04-07 0:17 ` Richard Stallman 1 sibling, 2 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-06 8:40 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel, rms, monnier > From: Bastien <bzg@gnu.org> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, eliz@gnu.org, emacs-devel@gnu.org > 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 8:40 ` Eli Zaretskii @ 2012-04-06 9:20 ` Bastien 2012-04-06 9:57 ` Eli Zaretskii 2012-04-06 16:17 ` Christophe Poncy 1 sibling, 1 reply; 85+ messages in thread From: Bastien @ 2012-04-06 9:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, rms, monnier Eli Zaretskii <eliz@gnu.org> writes: >> From: Bastien <bzg@gnu.org> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, eliz@gnu.org, emacs-devel@gnu.org >> 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...) - Some people don't have access to their Emacs installation (at work, for example) and still want the latest Org. 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. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 9:20 ` Bastien @ 2012-04-06 9:57 ` Eli Zaretskii 2012-04-06 10:20 ` Bastien 2012-04-16 10:45 ` Jason Rumney 0 siblings, 2 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-06 9:57 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel, rms, monnier > From: Bastien <bzg@gnu.org> > Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 06 Apr 2012 11:20:18 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Bastien <bzg@gnu.org> > >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, eliz@gnu.org, emacs-devel@gnu.org > >> 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. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 9:57 ` Eli Zaretskii @ 2012-04-06 10:20 ` Bastien 2012-04-06 17:26 ` chad 2012-04-16 10:45 ` Jason Rumney 1 sibling, 1 reply; 85+ messages in thread From: Bastien @ 2012-04-06 10:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, rms, monnier Eli Zaretskii <eliz@gnu.org> writes: >> From: Bastien <bzg@gnu.org> >> Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Fri, 06 Apr 2012 11:20:18 +0200 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> >> From: Bastien <bzg@gnu.org> >> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, eliz@gnu.org, emacs-devel@gnu.org >> >> 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 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 10:20 ` Bastien @ 2012-04-06 17:26 ` chad 2012-04-06 20:01 ` joakim 0 siblings, 1 reply; 85+ messages in thread From: chad @ 2012-04-06 17:26 UTC (permalink / raw) To: Bastien; +Cc: Eli Zaretskii, rms, monnier, emacs-devel On Apr 6, 2012, at 3:20 AM, Bastien wrote: >> 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. Both the Bazaar and git people agree that bazaar/git is faster than git/bazaar on some things and slower on others. Eli is (I believe) curious about what things you're doing that seem importantly faster on git. The bazaar doc you reference says specifically this about speed: Git is faster but Bazaar is clearly fast enough for 99.9% of users. If Bazaar 2.x is genuinely too slow for you on your project, please tell us where and we’ll do what we can to fix the problem for you. Like emacs versus vi, this question has quite a lot of ``well-known knowledge'' that is widely spread, oft-quoted, and generally untrue. That isn't meant to imply that your experience is invalid; simply to point out that `the common conception says...' is often well off the mark in this area. > 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. True, very true. It is *perhaps* worth talking about as a `background task', though, because there are many VCS things that become much easier if two linked systems use the *same* dVCS, and Emacs seems very likely to stick with Bazaar for philosophical reasons. I hope that helps, *Chad ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 17:26 ` chad @ 2012-04-06 20:01 ` joakim 2012-04-06 20:52 ` Eli Zaretskii 2012-04-06 21:10 ` Juanma Barranquero 0 siblings, 2 replies; 85+ messages in thread From: joakim @ 2012-04-06 20:01 UTC (permalink / raw) To: chad; +Cc: Bastien, Eli Zaretskii, emacs-devel, rms, monnier chad <yandros@MIT.EDU> writes: > On Apr 6, 2012, at 3:20 AM, Bastien wrote: >>> 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. > > Both the Bazaar and git people agree that bazaar/git is faster than git/bazaar on some things and slower on others. Eli is (I believe) curious about what things you're doing that seem importantly faster on git. > > The bazaar doc you reference says specifically this about speed: > > Git is faster but Bazaar is clearly fast enough for 99.9% of > users. If Bazaar 2.x is genuinely too slow for you on your > project, please tell us where and we’ll do what we can to fix > the problem for you. > > Like emacs versus vi, this question has quite a lot of ``well-known knowledge'' that is widely spread, oft-quoted, and generally untrue. That isn't meant to imply that your experience is invalid; simply to point out that `the common conception says...' is often well off the mark in this area. > >> 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. > > True, very true. It is *perhaps* worth talking about as a `background task', though, because there are many VCS things that become much easier if two linked systems use the *same* dVCS, and Emacs seems very likely to stick with Bazaar for philosophical reasons. I hesitate to inject more noise, but here goes anyway. I use bzr for Emacs and Inkscape, Git for most other projects, Svn at work. Bzr is okay for most things, except it lacks co-located branches, and has some bugs. I tried using the "loom" plugin for a while, but then the repository format became incompatible with upstream. I tried the git-bzr git plugin for a while but that didn't work too well because of bugs in bzr fastimport. (these bugs are reported upstream) The thing I would like to achieve in the Emacs case that is tedious with bzr is to maintain a long lived branch(the emacs xwidgets branch), together with some various patches, and use these as my local primary Emacs. This workflow is pretty convenient in Git with colocated branches. AFAIK it is a planned feature for Bzr but it's not ready yet. I feel I provide less Emacs patches than I could because of this lack. I would be interested to know how other Emacs developers handle this situation. Perhaps there is something I am missing? > > I hope that helps, > *Chad > > > -- Joakim Verona ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 20:01 ` joakim @ 2012-04-06 20:52 ` Eli Zaretskii 2012-04-07 2:28 ` Óscar Fuentes 2012-04-06 21:10 ` Juanma Barranquero 1 sibling, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-06 20:52 UTC (permalink / raw) To: joakim; +Cc: bzg, yandros, emacs-devel, rms, monnier > From: joakim@verona.se > Cc: Bastien <bzg@gnu.org>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 06 Apr 2012 22:01:57 +0200 > > Bzr is okay for most things, except it lacks co-located branches As of v2.5.0 (the latest stable release), bzr supports co-located branches in the core, so no plugins are necessary. (I didn't use it, so I cannot share any experience.) > I tried the git-bzr git plugin for a while but that didn't work too > well because of bugs in bzr fastimport. When did you last try that? AFAIK, all the significant bugs are now fixed, and in fact bzr-git is bundled with the official release. For me, the main disadvantage of bzr-git is that the initial branch (a.k.a. clone) command is painfully slow, because bzr needs to convert all the git meta-data to bzr format. (After the initial branch creation, pulling is quite bearable.) But other than that, its integration with bzr is very good, and starting with bzr 2.5, you can clone all the branches, not just master, and pull separately from each branch. > This workflow is pretty convenient in Git with colocated > branches. AFAIK it is a planned feature for Bzr but it's not ready yet. The future is here, see above. You may wish to give it another try. > I feel I provide less Emacs patches than I could because of this lack. I > would be interested to know how other Emacs developers handle this > situation. Perhaps there is something I am missing? FWIW, I like having separate branches. At least for Emacs, and for the use case when the changes in the branch are significant (like what I had for bidi), co-located branches get in the way because switching branches needs to make a lot of changes, and requires a large build if not a full bootstrap. So having several branches sharing the same tree does not gain much, and their disadvantage -- the possibility to forget what branch is the current one and mess up -- is not worth that gain. YMMV, of course. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 20:52 ` Eli Zaretskii @ 2012-04-07 2:28 ` Óscar Fuentes 2012-04-07 6:33 ` Eli Zaretskii 2012-04-07 7:07 ` Andreas Schwab 0 siblings, 2 replies; 85+ messages in thread From: Óscar Fuentes @ 2012-04-07 2:28 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: [snip] > FWIW, I like having separate branches. At least for Emacs, and for > the use case when the changes in the branch are significant (like what > I had for bidi), co-located branches get in the way because switching > branches needs to make a lot of changes, and requires a large build if > not a full bootstrap. Use out-of-source builds, with a build directory per branch... unless that collides with Emacs' peculiar practice of putting build products on the source tree for out-of-source builds. On addition, when I switch branches from Emacs the relevant function is advised for storing timestamps of the files of the current branch before the switch and recover the timestamps of the new branch's files after the switch, so no rebuild is triggered because some source file was modified by the switch when the new branch already has an associated up to date build. > So having several branches sharing the same > tree does not gain much, and their disadvantage -- the possibility to > forget what branch is the current one and mess up -- is not worth that > gain. [snip] vc-git solves this by displaying the current branch name on the modeline. vc-bzr could do the same if colocated branches gain popularity. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 2:28 ` Óscar Fuentes @ 2012-04-07 6:33 ` Eli Zaretskii 2012-04-07 11:56 ` Óscar Fuentes 2012-04-07 7:07 ` Andreas Schwab 1 sibling, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-07 6:33 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Sat, 07 Apr 2012 04:28:46 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > [snip] > > > FWIW, I like having separate branches. At least for Emacs, and for > > the use case when the changes in the branch are significant (like what > > I had for bidi), co-located branches get in the way because switching > > branches needs to make a lot of changes, and requires a large build if > > not a full bootstrap. > > Use out-of-source builds, with a build directory per branch... What for? I have no problems with the above arrangement. Joakim asked how others arrange their branches, and I described mine. There are no problems I have that would require me to change it. > unless that collides with Emacs' peculiar practice of putting build > products on the source tree for out-of-source builds. Nothing peculiar here: the Windows build simply doesn't support out-of-source builds. But I build inside the source tree on GNU/Linux as well, so that's not the main reason. > On addition, when I switch branches from Emacs the relevant function is > advised for storing timestamps of the files of the current branch before > the switch and recover the timestamps of the new branch's files after > the switch, so no rebuild is triggered because some source file was > modified by the switch when the new branch already has an associated up > to date build. IMO, this is a dangerous practice, because you cannot always second-guess what needs to be rebuilt after the switch, what with all the complex Makefile rules. In any case, if you have branches in separate directories, you get that for free. > vc-git solves this by displaying the current branch name on the > modeline. vc-bzr could do the same if colocated branches gain > popularity. You are assuming that I use VC to do my bzr operations. That's false. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 6:33 ` Eli Zaretskii @ 2012-04-07 11:56 ` Óscar Fuentes 2012-04-07 12:10 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2012-04-07 11:56 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > FWIW, I like having separate branches. At least for Emacs, and for >> > the use case when the changes in the branch are significant (like what >> > I had for bidi), co-located branches get in the way because switching >> > branches needs to make a lot of changes, and requires a large build if >> > not a full bootstrap. >> >> Use out-of-source builds, with a build directory per branch... > > What for? I have no problems with the above arrangement. Joakim > asked how others arrange their branches, and I described mine. There > are no problems I have that would require me to change it. You mentioned some problems with colocated branches, and I described a method for avoiding them. I'm not trying to convince you to change anything. >> unless that collides with Emacs' peculiar practice of putting build >> products on the source tree for out-of-source builds. > > Nothing peculiar here: the Windows build simply doesn't support > out-of-source builds. But I build inside the source tree on GNU/Linux > as well, so that's not the main reason. The GNU/Linux build also puts products on the source tree (the .elc files). >> On addition, when I switch branches from Emacs the relevant function is >> advised for storing timestamps of the files of the current branch before >> the switch and recover the timestamps of the new branch's files after >> the switch, so no rebuild is triggered because some source file was >> modified by the switch when the new branch already has an associated up >> to date build. > > IMO, this is a dangerous practice, because you cannot always > second-guess what needs to be rebuilt after the switch, what with all > the complex Makefile rules. There is nothing dangerous about that, because you don't need to second-guess. > In any case, if you have branches in separate directories, you get > that for free. This is for people who prefer to use colocated branches. >> vc-git solves this by displaying the current branch name on the >> modeline. vc-bzr could do the same if colocated branches gain >> popularity. > > You are assuming that I use VC to do my bzr operations. That's false. What you use for "bzr operations" have nothing to do with the information displayed on the modeline, which helps hackers who use colocated branches to know all the time which branch they are working on. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 11:56 ` Óscar Fuentes @ 2012-04-07 12:10 ` Eli Zaretskii 2012-04-07 12:56 ` Óscar Fuentes 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-07 12:10 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Sat, 07 Apr 2012 13:56:50 +0200 > > >> vc-git solves this by displaying the current branch name on the > >> modeline. vc-bzr could do the same if colocated branches gain > >> popularity. > > > > You are assuming that I use VC to do my bzr operations. That's false. > > What you use for "bzr operations" have nothing to do with the > information displayed on the modeline, which helps hackers who use > colocated branches to know all the time which branch they are working > on. It helps only if one looks at the modeline when invoking the VCS commands. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 12:10 ` Eli Zaretskii @ 2012-04-07 12:56 ` Óscar Fuentes 2012-04-07 13:32 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Óscar Fuentes @ 2012-04-07 12:56 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > You are assuming that I use VC to do my bzr operations. That's false. >> >> What you use for "bzr operations" have nothing to do with the >> information displayed on the modeline, which helps hackers who use >> colocated branches to know all the time which branch they are working >> on. > > It helps only if one looks at the modeline when invoking the VCS > commands. If the current branch name is displayed on the modeline for the files that belong to that branch, it helps whenever you look at it, doesn't it? ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 12:56 ` Óscar Fuentes @ 2012-04-07 13:32 ` Eli Zaretskii 2012-04-07 13:42 ` Óscar Fuentes 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-07 13:32 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Sat, 07 Apr 2012 14:56:39 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> > You are assuming that I use VC to do my bzr operations. That's false. > >> > >> What you use for "bzr operations" have nothing to do with the > >> information displayed on the modeline, which helps hackers who use > >> colocated branches to know all the time which branch they are working > >> on. > > > > It helps only if one looks at the modeline when invoking the VCS > > commands. > > If the current branch name is displayed on the modeline for the files > that belong to that branch, it helps whenever you look at it, doesn't > it? What I meant was that when you invoke a VCS command, you need to be aware which branch is the current one, or you might invoke a wrong command. When you invoke a VCS command, the modeline is not necessarily in your field of view, especially if the command is not invoked from Emacs. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 13:32 ` Eli Zaretskii @ 2012-04-07 13:42 ` Óscar Fuentes 0 siblings, 0 replies; 85+ messages in thread From: Óscar Fuentes @ 2012-04-07 13:42 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > What I meant was that when you invoke a VCS command, you need to be > aware which branch is the current one, or you might invoke a wrong > command. When you invoke a VCS command, the modeline is not > necessarily in your field of view, especially if the command is not > invoked from Emacs. Well, if you are working outside of Emacs then you can't only blame your tools for the inconvenience. Within Emacs, there is no room for confusion when you use git colocated branches, at least with vc-git + magit. I see no reason why working with bzr colocated branches on Emacs couldn't be as safe as git's. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 2:28 ` Óscar Fuentes 2012-04-07 6:33 ` Eli Zaretskii @ 2012-04-07 7:07 ` Andreas Schwab 2012-04-07 11:44 ` Óscar Fuentes 1 sibling, 1 reply; 85+ messages in thread From: Andreas Schwab @ 2012-04-07 7:07 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > On addition, when I switch branches from Emacs the relevant function is > advised for storing timestamps of the files of the current branch before > the switch and recover the timestamps of the new branch's files after > the switch, so no rebuild is triggered because some source file was > modified by the switch when the new branch already has an associated up > to date build. Whatfor? git doesn't touch files that didn't change when checking out a different revision. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 7:07 ` Andreas Schwab @ 2012-04-07 11:44 ` Óscar Fuentes 0 siblings, 0 replies; 85+ messages in thread From: Óscar Fuentes @ 2012-04-07 11:44 UTC (permalink / raw) To: emacs-devel Andreas Schwab <schwab@linux-m68k.org> writes: > Óscar Fuentes <ofv@wanadoo.es> writes: > >> On addition, when I switch branches from Emacs the relevant function is >> advised for storing timestamps of the files of the current branch before >> the switch and recover the timestamps of the new branch's files after >> the switch, so no rebuild is triggered because some source file was >> modified by the switch when the new branch already has an associated up >> to date build. > > Whatfor? git doesn't touch files that didn't change when checking out a > different revision. The point is to keep the timestamps of the files that did change: 1. while in branch A, build the project; build products go to build/A directory. 2. switch to branch B. 3. switch to branch A. All the files that are different among those branches now have altered timestamps, so `make' thinks the products on build/A are out of date, when in fact they are not. The scheme I described avoids this situation. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 20:01 ` joakim 2012-04-06 20:52 ` Eli Zaretskii @ 2012-04-06 21:10 ` Juanma Barranquero 1 sibling, 0 replies; 85+ messages in thread From: Juanma Barranquero @ 2012-04-06 21:10 UTC (permalink / raw) To: joakim; +Cc: emacs-devel On Fri, Apr 6, 2012 at 22:01, <joakim@verona.se> wrote: > Bzr is okay for most things, except it lacks co-located branches From the 2.5.0 announcement: "The 2.5 series provides a faster smart protocol implementation for many operations, basic support for colocated branches." So it's almost there. Juanma ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 9:57 ` Eli Zaretskii 2012-04-06 10:20 ` Bastien @ 2012-04-16 10:45 ` Jason Rumney 2012-04-16 16:38 ` Eli Zaretskii 1 sibling, 1 reply; 85+ messages in thread From: Jason Rumney @ 2012-04-16 10:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Bastien, rms, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I believe this is just the general git-preference issue, which has > nothing to do with "faster". You can beleive what you want. At the end of a slow link, bzr is painfully slow. A lot less painful now than it was when we first started using it, but still more painful than git or cvs ever was. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-16 10:45 ` Jason Rumney @ 2012-04-16 16:38 ` Eli Zaretskii 0 siblings, 0 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-16 16:38 UTC (permalink / raw) To: Jason Rumney; +Cc: bzg, rms, monnier, emacs-devel > From: Jason Rumney <jasonr@gnu.org> > Cc: Bastien <bzg@gnu.org>, emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca > Date: Mon, 16 Apr 2012 18:45:32 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > I believe this is just the general git-preference issue, which has > > nothing to do with "faster". > > You can beleive what you want. At the end of a slow link, bzr is > painfully slow. A lot less painful now than it was when we first started > using it, but still more painful than git or cvs ever was. I don't think anyone of the involved parties is at the end of a slow link. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 8:40 ` Eli Zaretskii 2012-04-06 9:20 ` Bastien @ 2012-04-06 16:17 ` Christophe Poncy 2012-04-06 16:41 ` Eli Zaretskii 2012-04-07 0:17 ` Richard Stallman 1 sibling, 2 replies; 85+ messages in thread From: Christophe Poncy @ 2012-04-06 16:17 UTC (permalink / raw) To: emacs-devel On Fri, 06 Apr 2012 11:40:18 +0300, Eli Zaretskii wrote: >> From: Bastien <bzg@gnu.org> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, eliz@gnu.org, >> emacs-devel@gnu.org >> 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. It's so easy and convenient to get their latest development release from their git repo. I must confess that I like this way to stay up to date. I would love to do the same with emacs ;) ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 16:17 ` Christophe Poncy @ 2012-04-06 16:41 ` Eli Zaretskii 2012-04-06 17:14 ` Christophe Poncy 2012-04-07 0:17 ` Richard Stallman 1 sibling, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-06 16:41 UTC (permalink / raw) To: cp; +Cc: emacs-devel > Date: Fri, 06 Apr 2012 18:17:42 +0200 > From: Christophe Poncy <cp@canaxis.org> > > It's so easy and convenient to get their latest development release > from their git repo. I must confess that I like this way to stay up to > date. I would love to do the same with emacs ;) What is missing to allow you to do the same with Emacs? ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 16:41 ` Eli Zaretskii @ 2012-04-06 17:14 ` Christophe Poncy 0 siblings, 0 replies; 85+ messages in thread From: Christophe Poncy @ 2012-04-06 17:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Fri, 06 Apr 2012 19:41:06 +0300, Eli Zaretskii wrote: >> Date: Fri, 06 Apr 2012 18:17:42 +0200 >> From: Christophe Poncy <cp@canaxis.org> >> >> It's so easy and convenient to get their latest development release >> from their git repo. I must confess that I like this way to stay up >> to >> date. I would love to do the same with emacs ;) > > What is missing to allow you to do the same with Emacs? probably my fault, I got an error message after some time and never tried again. I never had this sort of problem with git for all other programs I am using this way... I understand this is not the point of this thread, so I am really sorry Eli to talk about that... ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 16:17 ` Christophe Poncy 2012-04-06 16:41 ` Eli Zaretskii @ 2012-04-07 0:17 ` Richard Stallman 1 sibling, 0 replies; 85+ messages in thread From: Richard Stallman @ 2012-04-07 0:17 UTC (permalink / raw) To: cp; +Cc: emacs-devel We use Bzr, and will continue to use Bzr, because that is a GNU package and git is not. GNU packages ought to help promote other GNU packages, because they are all part of one larger project: the GNU Project. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 8:29 ` Bastien 2012-04-06 8:40 ` Eli Zaretskii @ 2012-04-07 0:17 ` Richard Stallman 2012-04-07 9:15 ` Bastien 1 sibling, 1 reply; 85+ messages in thread From: Richard Stallman @ 2012-04-07 0:17 UTC (permalink / raw) To: Bastien; +Cc: eliz, monnier, emacs-devel As I see it, the main reason for Org to use a separate repository is to gather an active community around a central place. Regular Org testers don't want to rebuild Emacs each time they have to test a new feature in Org. Doesn't bzr allow them to do all the same things while using the Emacs repository? There is no legal reason for not using the Emacs repository as the canonical repository for Org. Just a practical one: doing so would force us to maintain the canonical Org repository in Emacs *and* another repository for things that are useful to Org and that cannot be part of Emacs. I am concerned that this practice is harmful. Would we want these things to be part of Emacs? If not, then it isn't a problem. But if so, distributing them with Org in this way is undermining our efforts. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 0:17 ` Richard Stallman @ 2012-04-07 9:15 ` Bastien 2012-04-07 22:19 ` Richard Stallman 2012-04-08 3:25 ` Richard Stallman 0 siblings, 2 replies; 85+ messages in thread From: Bastien @ 2012-04-07 9:15 UTC (permalink / raw) To: rms; +Cc: eliz, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > As I see it, the main reason for Org to use a separate repository > is to gather an active community around a central place. > > Regular Org testers don't want to rebuild Emacs each time they have > to test a new feature in Org. > > Doesn't bzr allow them to do all the same things while > using the Emacs repository? Yes, but it is more complicated for most users. > There is no legal reason for not using the Emacs repository as the > canonical repository for Org. Just a practical one: doing so would > force us to maintain the canonical Org repository in Emacs *and* > another repository for things that are useful to Org and that cannot > be part of Emacs. > > I am concerned that this practice is harmful. > Would we want these things to be part of Emacs? > If not, then it isn't a problem. For some of these things, we want them in Emacs. For others we don't want them in Emacs. For some we simply don't know. For things we want to be in Org's core and then in GNU Emacs, having a separate contrib/ repository is a way to give everyone access to code from authors that signed the FSF papers but whose papers are not yet processed by the FSF. For other things, having them in Org's repo makes sense, because it is a central place for anything related to Org. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 9:15 ` Bastien @ 2012-04-07 22:19 ` Richard Stallman 2012-04-09 9:39 ` Bastien 2012-04-08 3:25 ` Richard Stallman 1 sibling, 1 reply; 85+ messages in thread From: Richard Stallman @ 2012-04-07 22:19 UTC (permalink / raw) To: Bastien; +Cc: eliz, monnier, emacs-devel > Doesn't bzr allow them to do all the same things while > using the Emacs repository? Yes, but it is more complicated for most users. Could we find a way to make it simpler, I wonder? Perhaps some scripts? Or new bzr features? For things we want to be in Org's core and then in GNU Emacs, having a separate contrib/ repository is a way to give everyone access to code from authors that signed the FSF papers but whose papers are not yet processed by the FSF. We are working on speeding this up. I hope it will get done in a few months. I can't promise it, or give details yet. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 22:19 ` Richard Stallman @ 2012-04-09 9:39 ` Bastien 0 siblings, 0 replies; 85+ messages in thread From: Bastien @ 2012-04-09 9:39 UTC (permalink / raw) To: rms; +Cc: eliz, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > For things we want to be in Org's core and then in GNU Emacs, having > a separate contrib/ repository is a way to give everyone access to code > from authors that signed the FSF papers but whose papers are not yet > processed by the FSF. > > We are working on speeding this up. I hope it will get done in a few > months. I can't promise it, or give details yet. Thanks! -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-07 9:15 ` Bastien 2012-04-07 22:19 ` Richard Stallman @ 2012-04-08 3:25 ` Richard Stallman 2012-04-08 15:52 ` Ted Zlatanov 1 sibling, 1 reply; 85+ messages in thread From: Richard Stallman @ 2012-04-08 3:25 UTC (permalink / raw) To: Bastien; +Cc: eliz, monnier, emacs-devel For other things, having them in Org's repo makes sense, because it is a central place for anything related to Org. Is it possible to have two repositories that partly overlap and partly don't? I would think that it ought to be possible with a DVCS. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-08 3:25 ` Richard Stallman @ 2012-04-08 15:52 ` Ted Zlatanov 2012-04-16 22:02 ` Richard Stallman 0 siblings, 1 reply; 85+ messages in thread From: Ted Zlatanov @ 2012-04-08 15:52 UTC (permalink / raw) To: emacs-devel On Sat, 07 Apr 2012 23:25:41 -0400 Richard Stallman <rms@gnu.org> wrote: RS> For other things, having them in Org's repo makes sense, because it RS> is a central place for anything related to Org. RS> Is it possible to have two repositories that partly overlap RS> and partly don't? I would think that it ought to be possible RS> with a DVCS. Yes, but it's very hard to keep them synchronized without a merge manager, especially if you have to convert between Git and Bazaar. For Gnus we have Yamaoka-san who keeps us sane, doing the merges in a semi-automatic way. I tried to get something automatic between Gnus and Emacs working last year and was unable to convince Bazaar to do what I wanted, after a few days of hacking. Perhaps it's a matter of training and dedication I lacked; if anyone has *automated* the merge workflow between Git and Bazaar for two large, partially overlapping and with many files renamed, repositories, I'd love to know how it can be done. Ted ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-08 15:52 ` Ted Zlatanov @ 2012-04-16 22:02 ` Richard Stallman 0 siblings, 0 replies; 85+ messages in thread From: Richard Stallman @ 2012-04-16 22:02 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-devel Yes, but it's very hard to keep them synchronized without a merge manager, especially if you have to convert between Git and Bazaar. Maybe scripts could be designed for the specific shared repository. And you don't have to use Git. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr 2012-04-06 7:13 ` Richard Stallman 2012-04-06 8:29 ` Bastien @ 2012-04-06 8:43 ` Eli Zaretskii 1 sibling, 0 replies; 85+ messages in thread From: Eli Zaretskii @ 2012-04-06 8:43 UTC (permalink / raw) To: rms; +Cc: bzg, monnier, emacs-devel > Date: Fri, 06 Apr 2012 03:13:09 -0400 > From: Richard Stallman <rms@gnu.org> > CC: eliz@gnu.org, bzg@gnu.org, emacs-devel@gnu.org > > As for practical reasons, doesn't the flexibility of a DVCS > make them go away? It probably would, except that most of those projects don't use Bazaar. There are no ways (AFAIK) to sync on a day-to-day basis 2 repositories maintained by 2 different VCSes. By contrast, there _are_ several potential solutions if you use a single dVCS. Git supports nested repositories (IIUC), and bzr has a couple of plugins to do something similar. ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-03 13:42 ` Bastien ` (2 preceding siblings ...) 2012-04-03 15:32 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Stefan Monnier @ 2012-04-04 17:12 ` Eli Zaretskii 2012-04-05 7:13 ` Bastien 2012-04-04 18:01 ` Thierry Volpiatto 4 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-04 17:12 UTC (permalink / raw) To: Bastien; +Cc: ofv, emacs-devel > From: Bastien <bzg@gnu.org> > Date: Tue, 03 Apr 2012 15:42:24 +0200 > Cc: emacs-devel@gnu.org > > The problem is: how to create a patch from Org git repo that can be > easily applied to Emacs bzr repo. > > If someone can come up with a workable solution, that'd help me a lot. Can you describe your current workflow in this respect? I mean, the last thing you probably want to hear is a suggestion for a workflow that you already use, albeit imperfectly... ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-04 17:12 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Eli Zaretskii @ 2012-04-05 7:13 ` Bastien 2012-04-05 15:53 ` Eli Zaretskii 0 siblings, 1 reply; 85+ messages in thread From: Bastien @ 2012-04-05 7:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel Hi Eli, Eli Zaretskii <eliz@gnu.org> writes: >> From: Bastien <bzg@gnu.org> >> Date: Tue, 03 Apr 2012 15:42:24 +0200 >> Cc: emacs-devel@gnu.org >> >> The problem is: how to create a patch from Org git repo that can be >> easily applied to Emacs bzr repo. >> >> If someone can come up with a workable solution, that'd help me a lot. > > Can you describe your current workflow in this respect? I mean, the > last thing you probably want to hear is a suggestion for a workflow > that you already use, albeit imperfectly... Org git repo has three branches: - "maint" = branch for releases only - "hotfix" = branch for hotfixes against the current release - "master" = the development branch Hotfixes go to... hotfix, while ordinary development goes to master. For minor releases, we merge hotfix to maint. For major release, we merge master to maint. We add a release tag from maint. For the Emacs sync: So far, I *copied* files from the hotfix branch to Emacs, trying to review the diff before committing (obviously my brain has been asleep when I did this, and I relied too much on the assumption that I correctly backported changes to Org in Emacs to the Org git repo.) From now on, here is what I will try to do. I have a local "emacs-merge" branch, stemming from hotfix. This local branch has a directory "emacs" that reproduce part of the hierarchy of Emacs files, that part which contains Org files. doc misc ChangeLog org.texi etc org OrgOdtContentTemplate.xml OrgOdtStyles.xml README refcards orgcard.pdf orgcard.tex lisp org ChangeLog [org/ob..el]x109 Then the sync process is this: 1. Check for org-related changes in Emacs trunk 2. Backport them to the hotfix branch 3. Copy the files from the hotfix branch to the emacs dir in my local emacs-merge branch, and get a diff from there. 4. Clean up the patch so that it applies correctly in Emacs trunk. 5. Fix merge conflicts in the hotfix branch and go back to 3 if needed. 6. Commit the diff on the "org" bzr branch (bound to the remote Emacs trunk) when things look fine. Suggestions against this workflow are welcome. -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-05 7:13 ` Bastien @ 2012-04-05 15:53 ` Eli Zaretskii 2012-04-11 14:36 ` Bastien 0 siblings, 1 reply; 85+ messages in thread From: Eli Zaretskii @ 2012-04-05 15:53 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel > From: Bastien <bzg@gnu.org> > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > Date: Thu, 05 Apr 2012 09:13:09 +0200 > > I have a local "emacs-merge" branch, stemming from hotfix. This local > branch has a directory "emacs" that reproduce part of the hierarchy of > Emacs files, that part which contains Org files. > > doc > misc > ChangeLog > org.texi > etc > org > OrgOdtContentTemplate.xml > OrgOdtStyles.xml > README > refcards > orgcard.pdf > orgcard.tex > lisp > org > ChangeLog > [org/ob..el]x109 > > Then the sync process is this: > > 1. Check for org-related changes in Emacs trunk > > 2. Backport them to the hotfix branch > > 3. Copy the files from the hotfix branch to the emacs dir in my local > emacs-merge branch, and get a diff from there. > > 4. Clean up the patch so that it applies correctly in Emacs trunk. > > 5. Fix merge conflicts in the hotfix branch and go back to 3 if needed. > > 6. Commit the diff on the "org" bzr branch (bound to the remote Emacs > trunk) when things look fine. > > Suggestions against this workflow are welcome. Well, I'm not sure I get all the details of your setup, so it's possible that I will say something silly; apologies in advance. But IIUC, you could get away with less branches and less manual work. So here we go: Setup: . A bound bzr branch, let's call it emacs-trunk, where you don't make any changes, just merge before committing upstream, to the Emacs master repository. . A local bzr branch, let's call it emacs-org, which will be the branch that you sync with one of your git branches. From this branch you will merge to emacs-trunk before committing upstream. . A git branch that corresponds to emacs-org, I think this could be your hotfix branch, as I don't understand why you need the emacs-merge branch. Below I assume that you have the bzr-tiplog plugin installed. It provides the functionality similar to git-reflog, and lets you skip the error-prone step of remembering or keeping notes about the last bzr revision you sync'ed with (see below); the only revision id's you will ever need to remember is tip:0 and tip:1. The sync process proceeds in cycles. Each cycle begins when you sync from Emacs repo to Org as follows: cd emacs-trunk bzr update cd ../emacs-org bzr merge --pull ../emacs-trunk Now emacs-org is synchronized with the Emacs trunk. Next, produce the org-related changes since your last synchronization: bzr diff -r tip:1..tip:0 lisp/org > patches (If there are files outside lisp/org that you are interested in, perhaps etc/NEWS or doc/misc/org.texi, mention them as well; bzr will produce diffs only for those files and directories, leaving out stuff you don't care about.) The file `patches' produced above includes files that are added, removed, and renamed, but not in the form of diffs (I think). So to make sure you don't miss those changes, do also this: bzr status -r tip:1..tip:0 lisp/org (again, add any other directories you are interested in), and examine the output for any non-text changes. Now sync your git branch, by (a) applying `patches' with Patch, and (b) performing any file operations. The latter should be done by hand, or you could perhaps write some simple script to parse the output of "bzr status" and do it for you. After this, you develop Org normally. I understand you have other branches, so you probably will wish to use git commands to merge the changes into them as well, and then back to the branch that you will later sync with bzr. I suggest to perform the steps above as frequent as you can, to avoid diverging too much from the Emacs trunk. That will make the second part of the cycle easier. I'd expect that more often than not, you will find that no changes were done that pertain to Org, so I don't think the burden will be too heavy. The advantage is that your code will be very similar to what the Emacs trunk has, so all your testing will not need to be redone when you merge with the latest trunk below. So time passes, and you decide you are ready to commit to the Emacs repo. Then, just overwrite the files in emacs-org with the corresponding files in your git branch (using rsync or some such), and type these bzr commands: cd emacs-org bzr commit -m "sync'ed with git revision 12345abcd" You now have a bzr branch that is synchronized with your git branch. Now find out how much you diverged from the trunk since the last resync: cd ../emacs-trunk bzr update bzr diff -r branch:../emacs-org.. lisp/org If the diffs this shows are insignificant enough, you can simply merge into trunk and commit: bzr merge ../emacs-org bzr ci -m "Merge from Org repo." If, however, enough time has passed since the last sync, and the diffs are non-trivial, you will have to merge back to emacs-org and retest: cd ../emacs-org bzr merge ../emacs-trunk # build and test cd ../emacs-trunk bzr merge ../emacs-org bzr ci -m "Merge from Org repo." This completes the cycle, and you are ready to begin the next one. HTH ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-05 15:53 ` Eli Zaretskii @ 2012-04-11 14:36 ` Bastien 0 siblings, 0 replies; 85+ messages in thread From: Bastien @ 2012-04-11 14:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Hi Eli, Eli Zaretskii <eliz@gnu.org> writes: > Well, I'm not sure I get all the details of your setup, so it's > possible that I will say something silly; apologies in advance. But > IIUC, you could get away with less branches and less manual work. So > here we go: Thanks a lot for the detailed workflow description. I don't have the bzr-tiplog plugin installed (I don't know how to install it), and just by reading the workflow I don't feel really confortable in trying it... Here is the one I used for the sync this morning: ~$ cd install/git/ ~$ git clone git://git.savannah.gnu.org/emacs.git ~$ cd emacs ~$ git checkout emacs-24 ~$ cd ~/install/git/org-mode/ ~$ git checkout maint [the branch in sync with Emacs] ~$ cp [files from Emacs] [to files from Org] ~$ git diff > ~/emacs-sync.diff ~$ [review the diff and apply it to the maint branch] ~$ git checkout hotfix ~$ git merge maint [merge changes from Emacs] ~$ [release new Org (minor) version] ~$ git checkout maint ~$ git merge hotfix ~$ copy files from Org to Emacs (git) ~$ git diff [in Emacs git, to get the diff] ~$ review the patch and apply it to bzr emacs-24 if correct Most of this can be automated with a few scripts, and I try to avoid bzr, because using Magit for git diff and other operations is really handy. Best, -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-03 13:42 ` Bastien ` (3 preceding siblings ...) 2012-04-04 17:12 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Eli Zaretskii @ 2012-04-04 18:01 ` Thierry Volpiatto 2012-04-05 7:19 ` Bastien 4 siblings, 1 reply; 85+ messages in thread From: Thierry Volpiatto @ 2012-04-04 18:01 UTC (permalink / raw) To: emacs-devel > The problem is: how to create a patch from Org git repo that can be > easily applied to Emacs bzr repo. Org git repo ==> convert to mercurial ==> clone to mercurial qpatch make your changes here and apply the resulting(s) patche(s) to Emacs bzr repo. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-04 18:01 ` Thierry Volpiatto @ 2012-04-05 7:19 ` Bastien 2012-04-05 9:16 ` Thierry Volpiatto 0 siblings, 1 reply; 85+ messages in thread From: Bastien @ 2012-04-05 7:19 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel Hi Thierry, Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: >> The problem is: how to create a patch from Org git repo that can be >> easily applied to Emacs bzr repo. > > Org git repo ==> convert to mercurial ==> clone to mercurial qpatch > make your changes here > and apply the resulting(s) > patche(s) to Emacs bzr repo. Please test this workflow *for real* and tell me if this is workable. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy] 2012-04-05 7:19 ` Bastien @ 2012-04-05 9:16 ` Thierry Volpiatto 0 siblings, 0 replies; 85+ messages in thread From: Thierry Volpiatto @ 2012-04-05 9:16 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel Bastien <bzg@gnu.org> writes: > Hi Thierry, > > Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: > >>> The problem is: how to create a patch from Org git repo that can be >>> easily applied to Emacs bzr repo. >> >> Org git repo ==> convert to mercurial ==> clone to mercurial qpatch >> make your changes here >> and apply the resulting(s) >> patche(s) to Emacs bzr repo. > > Please test this workflow *for real* and tell me if this is workable. Of course, the "Org git repo" should be the same beast as what is in "Emacs bzr repo" which is not the case. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Next pretest, and regressions policy 2012-04-01 12:37 ` =?utf-8?Q?=C3=93scar_Fuentes?= 2012-04-01 13:30 ` Stefan Monnier @ 2012-04-01 20:35 ` Bastien 1 sibling, 0 replies; 85+ messages in thread From: Bastien @ 2012-04-01 20:35 UTC (permalink / raw) To: =?utf-8?Q?=C3=93scar_Fuentes?=; +Cc: emacs-devel Hi Oscar, "=?utf-8?Q?=C3=93scar_Fuentes?=" <ofv@wanadoo.es> writes: > I suggest that, before syncing, you obtain a diff from the bzr (or git) > emacs repo that contains all changes to org since your last sync, commit > the diff onto your org sources and then proceed with the new sync. Understood. Thanks for the advice! -- Bastien ^ permalink raw reply [flat|nested] 85+ messages in thread
end of thread, other threads:[~2012-04-16 22:02 UTC | newest] Thread overview: 85+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-22 13:28 Next pretest, and regressions policy Chong Yidong 2012-03-31 10:15 ` Bastien 2012-04-01 9:55 ` Bastien 2012-04-01 12:37 ` =?utf-8?Q?=C3=93scar_Fuentes?= 2012-04-01 13:30 ` Stefan Monnier 2012-04-01 17:09 ` Chong Yidong 2012-04-01 20:32 ` Bastien 2012-04-02 4:12 ` Chong Yidong 2012-04-01 20:32 ` Bastien 2012-04-03 8:20 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Roland Winkler 2012-04-03 12:36 ` Óscar Fuentes 2012-04-03 13:42 ` Bastien 2012-04-03 15:02 ` patch vs. overwrite in bzr =?utf-8?Q?=C3=93scar_Fuentes?= 2012-04-03 15:03 ` David Engster 2012-04-03 16:31 ` Stefan Monnier 2012-04-03 17:40 ` Michael Albinus 2012-04-03 15:32 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Stefan Monnier 2012-04-03 16:52 ` patch vs. overwrite in bzr Glenn Morris 2012-04-03 20:50 ` Bastien 2012-04-03 21:27 ` Glenn Morris 2012-04-04 0:26 ` Stefan Monnier 2012-04-04 5:45 ` Bastien 2012-04-04 5:51 ` Bastien 2012-04-04 6:46 ` Michael Albinus 2012-04-04 8:35 ` Thierry Volpiatto 2012-04-04 13:20 ` Stefan Monnier 2012-04-04 16:39 ` Jordi Gutiérrez Hermoso 2012-04-04 16:52 ` Paul Eggert 2012-04-04 17:09 ` Eli Zaretskii 2012-04-04 17:53 ` Thierry Volpiatto 2012-04-04 19:07 ` Eli Zaretskii 2012-04-04 19:38 ` Thierry Volpiatto 2012-04-04 20:12 ` Eli Zaretskii 2012-04-04 13:16 ` Stefan Monnier 2012-04-04 17:01 ` Eli Zaretskii 2012-04-04 18:07 ` Stefan Monnier 2012-04-04 19:11 ` Eli Zaretskii 2012-04-04 20:11 ` David Engster 2012-04-04 22:06 ` Stefan Monnier 2012-04-05 3:09 ` Eli Zaretskii 2012-04-05 13:22 ` Stefan Monnier 2012-04-05 15:24 ` Lars Magne Ingebrigtsen 2012-04-05 15:57 ` Eli Zaretskii 2012-04-05 17:10 ` Ted Zlatanov 2012-04-06 7:13 ` Richard Stallman 2012-04-06 8:29 ` Bastien 2012-04-06 8:40 ` Eli Zaretskii 2012-04-06 9:20 ` Bastien 2012-04-06 9:57 ` Eli Zaretskii 2012-04-06 10:20 ` Bastien 2012-04-06 17:26 ` chad 2012-04-06 20:01 ` joakim 2012-04-06 20:52 ` Eli Zaretskii 2012-04-07 2:28 ` Óscar Fuentes 2012-04-07 6:33 ` Eli Zaretskii 2012-04-07 11:56 ` Óscar Fuentes 2012-04-07 12:10 ` Eli Zaretskii 2012-04-07 12:56 ` Óscar Fuentes 2012-04-07 13:32 ` Eli Zaretskii 2012-04-07 13:42 ` Óscar Fuentes 2012-04-07 7:07 ` Andreas Schwab 2012-04-07 11:44 ` Óscar Fuentes 2012-04-06 21:10 ` Juanma Barranquero 2012-04-16 10:45 ` Jason Rumney 2012-04-16 16:38 ` Eli Zaretskii 2012-04-06 16:17 ` Christophe Poncy 2012-04-06 16:41 ` Eli Zaretskii 2012-04-06 17:14 ` Christophe Poncy 2012-04-07 0:17 ` Richard Stallman 2012-04-07 0:17 ` Richard Stallman 2012-04-07 9:15 ` Bastien 2012-04-07 22:19 ` Richard Stallman 2012-04-09 9:39 ` Bastien 2012-04-08 3:25 ` Richard Stallman 2012-04-08 15:52 ` Ted Zlatanov 2012-04-16 22:02 ` Richard Stallman 2012-04-06 8:43 ` Eli Zaretskii 2012-04-04 17:12 ` patch vs. overwrite in bzr [was: Next pretest, and regressions policy] Eli Zaretskii 2012-04-05 7:13 ` Bastien 2012-04-05 15:53 ` Eli Zaretskii 2012-04-11 14:36 ` Bastien 2012-04-04 18:01 ` Thierry Volpiatto 2012-04-05 7:19 ` Bastien 2012-04-05 9:16 ` Thierry Volpiatto 2012-04-01 20:35 ` Next pretest, and regressions policy Bastien
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.