* Basic Bazaar guide for Emacs hackers. @ 2009-11-27 23:19 Óscar Fuentes 2009-11-28 1:23 ` Stephen J. Turnbull ` (4 more replies) 0 siblings, 5 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-27 23:19 UTC (permalink / raw) To: emacs-devel [Posted this to help-emacs by accident.] http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs I know some of you are pushing hard for introducing complete and correct dVCS practices among the Emacs developers. That is laudable but IMHO unrealistic to expect since day one. So it is intended as a minimum knowledge guide for not being left out. It is an appetizer too. If you think that it is the wrong way to (not) enter dVCS, I'll delete it or put a big warning sign at the beginning. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Basic Bazaar guide for Emacs hackers. 2009-11-27 23:19 Basic Bazaar guide for Emacs hackers Óscar Fuentes @ 2009-11-28 1:23 ` Stephen J. Turnbull 2009-11-28 1:48 ` Óscar Fuentes ` (2 more replies) 2009-11-28 10:05 ` Eli Zaretskii ` (3 subsequent siblings) 4 siblings, 3 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-28 1:23 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > I know some of you are pushing hard for introducing complete and correct > dVCS practices among the Emacs developers. What you are recommending is very easy for the individual developer but makes for a messy history. CVS *forces* you to either crap all over the history, or to refrain from committing until the patch is perfect. dVCS gives you an alternative: commit frequently until done, *then* push. Please insert a big warning to explain that developers who choose this workflow are making an antisocial choice of their own convenience over more informative logs for the project. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 1:23 ` Stephen J. Turnbull @ 2009-11-28 1:48 ` Óscar Fuentes 2009-11-28 2:05 ` Stefan Monnier 2009-11-28 3:10 ` Richard Stallman 2 siblings, 0 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-28 1:48 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > > I know some of you are pushing hard for introducing complete and correct > > dVCS practices among the Emacs developers. > > What you are recommending is very easy for the individual developer > but makes for a messy history. CVS *forces* you to either crap all > over the history, or to refrain from committing until the patch is > perfect. The approach *suggested* (not *recommended*) on that page, makes things worse than the current CVS practice? > dVCS gives you an alternative: commit frequently until done, > *then* push. > Please insert a big warning to explain that developers who choose this > workflow are making an antisocial choice of their own convenience > over more informative logs for the project. Fist of all, I shall note that what the page says is not intended to be a permanent practice (although it works fine for quick fixes and small changes). The page may be removed after a few months, once Emacs raises and official policy for committing to the master branch. So, if that practice does not turn things worse than now are wrt the VC history, does it make sense to scare people away with words like "antisocial"? If this is the case, I'll delete the page altogether. I don't want to promote antisocial behavior on the emacs developers. OTOH, have you considered the scenario consisting on people pushing changes into the master branch without fully understanding how they impact the history? I'm thinking on throwaway commits inadvertently pushed, etc. This will be a transient effect, but so is the approach described on the wiki page I wrote. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 1:23 ` Stephen J. Turnbull 2009-11-28 1:48 ` Óscar Fuentes @ 2009-11-28 2:05 ` Stefan Monnier 2009-11-28 7:10 ` Stephen J. Turnbull 2009-11-28 3:10 ` Richard Stallman 2 siblings, 1 reply; 77+ messages in thread From: Stefan Monnier @ 2009-11-28 2:05 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel >> I know some of you are pushing hard for introducing complete and correct >> dVCS practices among the Emacs developers. > What you are recommending is very easy for the individual developer > but makes for a messy history. As long as they only use CVS-style development, it shouldn't add any mess to the history. Stefan ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 2:05 ` Stefan Monnier @ 2009-11-28 7:10 ` Stephen J. Turnbull 0 siblings, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-28 7:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: Óscar Fuentes, emacs-devel Stefan Monnier writes: > > What you are recommending is very easy for the individual developer > > but makes for a messy history. > > As long as they only use CVS-style development, it shouldn't add any > mess to the history. Well, if you feel that way, I retract my statement, which was made on the basis of how I would expect to feel in your shoes. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 1:23 ` Stephen J. Turnbull 2009-11-28 1:48 ` Óscar Fuentes 2009-11-28 2:05 ` Stefan Monnier @ 2009-11-28 3:10 ` Richard Stallman 2009-11-28 3:48 ` Óscar Fuentes 2009-11-28 7:27 ` Stephen J. Turnbull 2 siblings, 2 replies; 77+ messages in thread From: Richard Stallman @ 2009-11-28 3:10 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: ofv, emacs-devel What you are recommending is very easy for the individual developer but makes for a messy history. Could you explain what you mean by messy? Objectively, which are the characteristics you consider messy? Knowing that, I could determine whether I agree with you. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 3:10 ` Richard Stallman @ 2009-11-28 3:48 ` Óscar Fuentes 2009-11-28 7:29 ` Stephen J. Turnbull 2009-11-28 7:27 ` Stephen J. Turnbull 1 sibling, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-11-28 3:48 UTC (permalink / raw) To: rms; +Cc: ofv, Stephen J. Turnbull, emacs-devel Richard Stallman <rms@gnu.org> writes: > What you are recommending is very easy for the individual developer > but makes for a messy history. > > Could you explain what you mean by messy? Objectively, which are the > characteristics you consider messy? Knowing that, I could determine > whether I agree with you. I think Stephen is mixing things here. People who work with dVCS often find convenient to commit to their local branches from time to time before the feature is complete. This is most convenient if you think on a complex feature that you divide on several parts. As you implement each part, you commit to your local branch. Once you completed the job, you send the changes upstream. This incorporates your local commits on the upstream branch. Usually the rest of developers are not interested on the steps you followed for implementing your feature, so they want to see in the history: Implemented feature FooMatic Instead of: Created stub functions Implemented the user interface Internal logic completed. Fixed a bug in foo-bar With Bazaar you still can see that "inner history" if you ask for it, but usually you don't care and seeing so many detail in the log would be quite annoying. If you imagine several developers doing the same at the same time the effect is even worse: the detailed inner history listed above would be mixed with the commits of other developers. That's part of the problem Stephen is talking about when he talks about "messy history". But the Emacs developers do not commit to CVS until the work is finished. So if you keep committing only when the changes are ready for mainline, the simple workflow I described on the wiki page is harmless on this aspect. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 3:48 ` Óscar Fuentes @ 2009-11-28 7:29 ` Stephen J. Turnbull 2009-11-29 1:16 ` Richard Stallman 0 siblings, 1 reply; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-28 7:29 UTC (permalink / raw) To: Óscar Fuentes; +Cc: ofv, rms, emacs-devel Óscar Fuentes writes: > With Bazaar you still can see that "inner history" if you ask for it, > but usually you don't care and seeing so many detail in the log would be > quite annoying. If you imagine several developers doing the same at the > same time the effect is even worse: the detailed inner history listed > above would be mixed with the commits of other developers. That's part > of the problem Stephen is talking about when he talks about "messy > history". Yes. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 7:29 ` Stephen J. Turnbull @ 2009-11-29 1:16 ` Richard Stallman 0 siblings, 0 replies; 77+ messages in thread From: Richard Stallman @ 2009-11-29 1:16 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: ofv, oscarfv, emacs-devel > With Bazaar you still can see that "inner history" if you ask for it, > but usually you don't care and seeing so many detail in the log would be > quite annoying. If you imagine several developers doing the same at the > same time the effect is even worse: the detailed inner history listed > above would be mixed with the commits of other developers. This is only an issue for changes large enough to have an inner history. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-28 3:10 ` Richard Stallman 2009-11-28 3:48 ` Óscar Fuentes @ 2009-11-28 7:27 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-28 7:27 UTC (permalink / raw) To: rms; +Cc: ofv, emacs-devel Richard Stallman writes: > What you are recommending is very easy for the individual developer > but makes for a messy history. > > Could you explain what you mean by messy? Objectively, which are the > characteristics you consider messy? Knowing that, I could determine > whether I agree with you. (1) VCS commit messages which are committed at the end of a protracted review tend to be less detailed and sometimes inaccurate, sometimes because they are not revised to reflect review, sometimes because the details are poorly remembered. Conversely, the kinds of effort needed to keep accurate information in logs are somewhat reduced by a practice of frequent commits. (In the workflow recommended by BzrForEmacsDevs, you get to have your cake and eat it too: "bzr log" by default shows the details of all the commits when used in the working branch, but only the summary log for the merge commit when used in mirrors of the trunk.) (2) Medium-sized repetitive tasks (such as updating a bunch of function calls from an obsolete API to the recommended one) tend to occur in several commits, interspersed with commits from other tasks. (3) Anything that can be considered a single task tends to get committed, even though a more global view would group it with other tasks. (4) People tend to commit everything in their workspace, including unrelated typo fixes and small bugfixes. Sometimes the additional changes aren't logged. This is an easy mistake to make occasionally, even if you normally take care about it. All of these can be ameliorated with discipline in a CVS-style workflow; for most people it seems to require substantially less effort to use feature branches to organize their work. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-27 23:19 Basic Bazaar guide for Emacs hackers Óscar Fuentes 2009-11-28 1:23 ` Stephen J. Turnbull @ 2009-11-28 10:05 ` Eli Zaretskii 2009-11-29 1:16 ` Richard Stallman ` (2 subsequent siblings) 4 siblings, 0 replies; 77+ messages in thread From: Eli Zaretskii @ 2009-11-28 10:05 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, > UNPARSEABLE_RELAY autolearn=unavailable version=3.1.0 > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Sat, 28 Nov 2009 00:19:02 +0100 > > http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs Thank you. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-27 23:19 Basic Bazaar guide for Emacs hackers Óscar Fuentes 2009-11-28 1:23 ` Stephen J. Turnbull 2009-11-28 10:05 ` Eli Zaretskii @ 2009-11-29 1:16 ` Richard Stallman 2009-11-29 4:38 ` Óscar Fuentes 2009-11-30 2:05 ` Karl Fogel 2009-11-30 6:44 ` Glenn Morris 4 siblings, 1 reply; 77+ messages in thread From: Richard Stallman @ 2009-11-29 1:16 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs It is nice and simple. I have one critique. Someone said that the term "checkout" for bound branches is deprecated. It might be a good idea to use the preferred term instead, and perhaps use a different, not-to-be-deprecated command as well. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 1:16 ` Richard Stallman @ 2009-11-29 4:38 ` Óscar Fuentes 2009-11-29 5:27 ` Stephen J. Turnbull 2009-11-30 15:52 ` Richard Stallman 0 siblings, 2 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-29 4:38 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs > > It is nice and simple. I have one critique. Someone said that the > term "checkout" for bound branches is deprecated. It might be a good > idea to use the preferred term instead, and perhaps use a different, > not-to-be-deprecated command as well. I thought about this at the beginning and decided to do that way because the document either uses undefined concepts known by CVS users or defines the concepts that are new to them, as it does for the shared repository. Replacing bzr checkout URL with bzr branch URL bzr bind will force me to explain what a Bazaar branch is and why it can be bound or unbound, and thus would introduce us into the field of multiple workflows, which is precisely what the document tries to avoid. I don't see the `checkout' command deprecated or with its current semantics changed anytime soon. This is a big change that would merit a dot-zero version, and AFAIK that's not expected for a long time. The terms are correct as per the "intended future" meaning, as we are indeed creating a "bound branch" (which is absolutely orthodox). Using the expression "heavyweight checkout" (or simply "checkout") is right too, as any Bazaar user will recognize its meaning for a long time, and even the term is profusely used on the documentation of the upcoming 2.1 version. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 4:38 ` Óscar Fuentes @ 2009-11-29 5:27 ` Stephen J. Turnbull 2009-11-29 5:52 ` Óscar Fuentes 2009-11-30 15:52 ` Richard Stallman 1 sibling, 1 reply; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-29 5:27 UTC (permalink / raw) To: Óscar Fuentes; +Cc: rms, emacs-devel Óscar Fuentes writes: > Replacing > > bzr checkout URL > > with > > bzr branch URL > bzr bind > > will force me to explain what a Bazaar branch is and why it can be bound > or unbound, and thus would introduce us into the field of multiple > workflows, which is precisely what the document tries to avoid. I agree. One caution I have is that in this case you probably should also avoid mentioning offline work, which requires understanding what "bound" means and either how to unbind or how to use the --local flag, and the implications of that for future work when reconnected. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 5:27 ` Stephen J. Turnbull @ 2009-11-29 5:52 ` Óscar Fuentes 2009-11-29 7:00 ` Stephen J. Turnbull 0 siblings, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-11-29 5:52 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: rms, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > will force me to explain what a Bazaar branch is and why it can be bound > > or unbound, and thus would introduce us into the field of multiple > > workflows, which is precisely what the document tries to avoid. > > I agree. One caution I have is that in this case you probably should > also avoid mentioning offline work, which requires understanding what > "bound" means and either how to unbind or how to use the --local flag, > and the implications of that for future work when reconnected. The document has two parts: the first gives you everything you need for commiting changes to Emacs' upstream and the second part hints at possibilities ("see what you are missing") for motivating people to learn more (and ends with a reference to your page). The second part is intentionally vague and having half-cooked concepts there is perfectly okay. For the implications of committing offline, I was thinking on the good-behaved CVS committer, as in the first part of the document. So going offline does not mean here changing his commit criteria, but simply deferring the sending of changes upstream. Do you think that this is still problematic? (due to the pre-push merge, for instance) If yes, I'll remove all explicit indications and leave just a note about the possibility of committing offline. Thanks for your comments. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 5:52 ` Óscar Fuentes @ 2009-11-29 7:00 ` Stephen J. Turnbull 2009-11-29 16:29 ` Óscar Fuentes 0 siblings, 1 reply; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-29 7:00 UTC (permalink / raw) To: Óscar Fuentes; +Cc: rms, emacs-devel Óscar Fuentes writes: > For the implications of committing offline, I was thinking on the > good-behaved CVS committer, as in the first part of the document. So > going offline does not mean here changing his commit criteria, but > simply deferring the sending of changes upstream. Do you think that this > is still problematic? I don't see a social workflow problem since everyone agrees that Emacs committers have been well-behaved in the CVS context. There's no reason to suppose that will change in a CVS-like context just because they're using Bazaar. However, there are technical issues and some complexity in explaining just what consequences offline commits have for your first commit after reconnecting. The behavior may be surprising to a new user. Also, Stefan mentioned having had some issue with bound branches too. > (due to the pre-push merge, for instance) If yes, I'll remove all > explicit indications and leave just a note about the possibility of > committing offline. How about: This workflow is designed with the assumption you'll be connected to the network whenever you want to commit. It is possible to commit when offline, but if you need to do that frequently, first consider moving to a branch-based workflow as described in BzrForEmacsDevs. If you still prefer this workflow, please ask; there are various methods, and which is best depends on your particular circumstances. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 7:00 ` Stephen J. Turnbull @ 2009-11-29 16:29 ` Óscar Fuentes 2009-11-30 1:36 ` Stephen J. Turnbull 0 siblings, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-11-29 16:29 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel Hello Stephen. "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > (due to the pre-push merge, for instance) If yes, I'll remove all > > explicit indications and leave just a note about the possibility of > > committing offline. > > How about: > > This workflow is designed with the assumption you'll be connected > to the network whenever you want to commit. It is possible to > commit when offline, but if you need to do that frequently, first > consider moving to a branch-based workflow as described in > BzrForEmacsDevs. If you still prefer this workflow, please ask; > there are various methods, and which is best depends on your > particular circumstances. I completely removed the reference to --local and simply explained that is possible to commit off-line referencing your page and emacs-devel as the authoritative sources for learning about that matter. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 16:29 ` Óscar Fuentes @ 2009-11-30 1:36 ` Stephen J. Turnbull 0 siblings, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 1:36 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > I completely removed the reference to --local and simply explained that > is possible to commit off-line referencing your page and emacs-devel as > the authoritative sources for learning about that matter. Sounds good. BTW, it's not really accurate to call it my page. Most of the content of the page is from Karl's edition, which in turn I think he said he borrowed much from the Bazaar tutorials. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-29 4:38 ` Óscar Fuentes 2009-11-29 5:27 ` Stephen J. Turnbull @ 2009-11-30 15:52 ` Richard Stallman 1 sibling, 0 replies; 77+ messages in thread From: Richard Stallman @ 2009-11-30 15:52 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel bzr checkout URL with bzr branch URL bzr bind will force me to explain what a Bazaar branch is and why it can be bound or unbound, Not necessarily. You can explain what the sequence of commands does, and refer people elsewhere if they want to learn about those individual commands. You can explain what a "bound branch" does and refer people elsewhere to learn about other kinds of branches. too, as any Bazaar user will recognize its meaning for a long time, and even the term is profusely used on the documentation of the upcoming 2.1 version. In that case, maybe it is fine to call this a "checkout". I'm just going on what someone else said here. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-27 23:19 Basic Bazaar guide for Emacs hackers Óscar Fuentes ` (2 preceding siblings ...) 2009-11-29 1:16 ` Richard Stallman @ 2009-11-30 2:05 ` Karl Fogel 2009-11-30 2:17 ` Lennart Borgman 2009-11-30 3:26 ` Óscar Fuentes 2009-11-30 6:44 ` Glenn Morris 4 siblings, 2 replies; 77+ messages in thread From: Karl Fogel @ 2009-11-30 2:05 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > [Posted this to help-emacs by accident.] > > http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs > > I know some of you are pushing hard for introducing complete and correct > dVCS practices among the Emacs developers. That is laudable but IMHO > unrealistic to expect since day one. So it is intended as a minimum > knowledge guide for not being left out. It is an appetizer too. > > If you think that it is the wrong way to (not) enter dVCS, I'll delete > it or put a big warning sign at the beginning. The more options we offer, the more confused people will be. Also, the more different workflows developers use, the more difficult it will be for us to support each other. Can we please not fall into this tar pit? :-) I hate to say this, knowing how hard you must have worked on it, but I'm worried the document will do more harm than good in the long run. IMHO, either delete it or maybe just put some kind of warning sign at the beginning, linking to [1]. Coming from the Subversion-and-CVS world, I needed less than a day to get used to the Bazaar/distributed way of working. It just isn't that hard. Anyone who works on Emacs can get used to it in about that amount of time. Sure, there will be little questions here and there, but the main loop documented at [1] will be comprehensible to all. No one here is saying we should introduce "complete and correct dVCS practices...since day one". I *am* saying that it is completely reasonable to expect Emacs developers to read and understand [1], and to work that way from that point forward, until they understand Bazaar well enough to vary their workflow as they wish. There's nothing wrong with the content of BzrQuickStartForEmacsDevs. It's just that if Emacs developers start doing things that way too, then the total support burden on the community goes up. We should not stimulate that situation if we can avoid it. Best, -Karl [1] http://www.emacswiki.org/emacs/BzrForEmacsDevs ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 2:05 ` Karl Fogel @ 2009-11-30 2:17 ` Lennart Borgman 2009-11-30 2:46 ` Stephen J. Turnbull 2009-11-30 3:26 ` Óscar Fuentes 1 sibling, 1 reply; 77+ messages in thread From: Lennart Borgman @ 2009-11-30 2:17 UTC (permalink / raw) To: Karl Fogel; +Cc: Óscar Fuentes, emacs-devel On Mon, Nov 30, 2009 at 3:05 AM, Karl Fogel <kfogel@red-bean.com> wrote: > > There's nothing wrong with the content of BzrQuickStartForEmacsDevs. > It's just that if Emacs developers start doing things that way too, then > the total support burden on the community goes up. We should not > stimulate that situation if we can avoid it. Interesting. In science someone (very familiar) said "make it simple, but not too simple". IMO the burden of not making it simple has often been neglected in free software development. It is like it did not matter. But I think it does in many ways. And it is often very complicated to understand what it too simple and what is not enough simple. Like here. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 2:17 ` Lennart Borgman @ 2009-11-30 2:46 ` Stephen J. Turnbull 0 siblings, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 2:46 UTC (permalink / raw) To: Lennart Borgman; +Cc: Karl Fogel, Óscar Fuentes, emacs-devel Lennart Borgman writes: > Interesting. In science someone (very familiar) said "make it simple, > but not too simple". And Saunders Mac Lane, who is not at all familiar -- except to some of you, I suspect -- said "[G]ood general theory does not search for the maximum generality, but for the right generality." ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 2:05 ` Karl Fogel 2009-11-30 2:17 ` Lennart Borgman @ 2009-11-30 3:26 ` Óscar Fuentes 2009-11-30 3:51 ` Karl Fogel 2009-11-30 5:01 ` Stephen J. Turnbull 1 sibling, 2 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-30 3:26 UTC (permalink / raw) To: emacs-devel Karl Fogel <kfogel@red-bean.com> writes: > Óscar Fuentes <ofv@wanadoo.es> writes: >> [Posted this to help-emacs by accident.] >> >> http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs >> >> I know some of you are pushing hard for introducing complete and correct >> dVCS practices among the Emacs developers. That is laudable but IMHO >> unrealistic to expect since day one. So it is intended as a minimum >> knowledge guide for not being left out. It is an appetizer too. >> >> If you think that it is the wrong way to (not) enter dVCS, I'll delete >> it or put a big warning sign at the beginning. > > The more options we offer, the more confused people will be. ... unless each person finds the option adequate for him among the available ones. What is confusing, IMHO, is to provide several options with similar degree of complexity, and that demand from the user to apply new concepts and see himself on not-yet-experienced scenarios for deciding which one is the right one for him. > Also, the more different workflows developers use, the more difficult > it will be for us to support each other. Forcing developers to use workflows that they do not understand creates support requests. Forcing developers to use workflows that they find gratuitously complicated scares them away. > Can we please not fall into this tar pit? :-) > > I hate to say this, knowing how hard you must have worked on it, but I'm > worried the document will do more harm than good in the long run. IMHO, > either delete it or maybe just put some kind of warning sign at the > beginning, linking to [1]. What's exactly the reason for the warning? Is it like they will damage the Emacs project if they choose that workflow? I don't think so. Maybe they damage themselves by not using a more effective workflow for their specific needs, but that is implicit all along the document and, really, it is up to them to pick wathever they find appropriate. And, actually, that workflow is perfectly fine for occassional contributors or people who work on simple tasks like quick-fixes. The document is a sort of "this is the minimum you need to know, but keep reading if you want more." Either the developer thinks that the workflow is adequate and he keeps contributing or he wants more and goes to your document. What's wrong with that? > Coming from the Subversion-and-CVS world, I needed less than a day to > get used to the Bazaar/distributed way of working. It just isn't that > hard. Funny. I come from CVS and Subversion too, but learning dVCS took me several days of highly motivated effort to re-program my mind. Maybe the difference among you and me is that I was not a Subversion developer and version control concepts were not in my mind all day long. I'm pretty sure that when you started your bzr usage all its underlying concepts were already familiar to you. > Anyone who works on Emacs can get used to it in about that amount of > time. Sure, there will be little questions here and there, but the > main loop documented at [1] will be comprehensible to all. > > No one here is saying we should introduce "complete and correct dVCS > practices...since day one". I *am* saying that it is completely > reasonable to expect Emacs developers to read and understand [1], and to > work that way from that point forward, until they understand Bazaar well > enough to vary their workflow as they wish. You are overestimating the Emacs developers. Not their intelligence or knowledge about CS. You are overestimating their commitment to the project. AFAIK most Emacs committers can't be considered "regular" contributors. All of them are volunteers. They appear, do some bug fixing, add features or even create a new framework, but then they vanish for months or years. Expecting from them to learn a fringe tool like Bazaar on certain "recommended" way and then not having to re-learn it when they come back after three months is unrealistic. Expecting from somebody, who simply wants to correct the bug that annoys him so much, to learn a new tool together with a series of new concepts and practices for creating a simple patch, is raising the entry barrier quite a bit. > There's nothing wrong with the content of BzrQuickStartForEmacsDevs. > It's just that if Emacs developers start doing things that way too, then > the total support burden on the community goes up. We should not > stimulate that situation if we can avoid it. The intent of the document is to *lower* the support burden. If a CVS committer (or anyone with CVS or Subversion experience) has problems putting into practice what's described there, then your guide will be absolutely incomprehensible for him. I have no problem at all deleting the document if it damages the transition to Bazaar. But so far, your reasons for doing it are not convincing at all to me and just demonstrates a misunderstanding of the demography of Emacs and their current VC practices. All this said with respect and appreciation. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 3:26 ` Óscar Fuentes @ 2009-11-30 3:51 ` Karl Fogel 2009-11-30 5:01 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: Karl Fogel @ 2009-11-30 3:51 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: >> The more options we offer, the more confused people will be. > > ... unless each person finds the option adequate for him among the > available ones. > > What is confusing, IMHO, is to provide several options with similar > degree of complexity, and that demand from the user to apply new > concepts and see himself on not-yet-experienced scenarios for deciding > which one is the right one for him. I agree, we should not do that. Are we doing that? My intention has always been to recommend http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors as the place to start. > I have no problem at all deleting the document if it damages the > transition to Bazaar. But so far, your reasons for doing it are not > convincing at all to me and just demonstrates a misunderstanding of the > demography of Emacs and their current VC practices. > > All this said with respect and appreciation. Understood. I'm beginning to realize it doesn't matter. Once Emacs switches, we'll see what people really need, and then we'll provide it. So I'm not going to worry about it. We'll switch, and there will be grumbling, and then it will be fine. IMHO, we already have prepared all the documentation we can in advance. Best, -K ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 3:26 ` Óscar Fuentes 2009-11-30 3:51 ` Karl Fogel @ 2009-11-30 5:01 ` Stephen J. Turnbull 2009-11-30 5:20 ` Óscar Fuentes 1 sibling, 1 reply; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 5:01 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > Karl Fogel <kfogel@red-bean.com> writes: > > The more options we offer, the more confused people will be. > > ... unless each person finds the option adequate for him among the > available ones. The problem is that people just don't do that when faced with several options. They pick the best features of each and expect the application to provide all of them. Or they don't like something so they tweak it. Then they get confused. > I have no problem at all deleting the document if it damages the > transition to Bazaar. But so far, your reasons for doing it are not > convincing at all to me and just demonstrates a misunderstanding of the > demography of Emacs and their current VC practices. On the other hand, how many VCS transitions have you managed for Emacs-sized projects? I've done two so far. I can say from experience the cost of support is not polynomial in extra workflows during the transition. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 5:01 ` Stephen J. Turnbull @ 2009-11-30 5:20 ` Óscar Fuentes 2009-11-30 6:03 ` Karl Fogel ` (2 more replies) 0 siblings, 3 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-30 5:20 UTC (permalink / raw) To: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > I have no problem at all deleting the document if it damages the > > transition to Bazaar. But so far, your reasons for doing it are not > > convincing at all to me and just demonstrates a misunderstanding of > > the demography of Emacs and their current VC practices. > > On the other hand, how many VCS transitions have you managed for > Emacs-sized projects? I've done two so far. I can say from > experience the cost of support is not polynomial in extra workflows > during the transition. Okay. Your experience trumps over my reasoning. Page deleted. But from now on I don't feel obliged to help supporting those who think that they have better things to do than learning a new way of doing something that worked fine for the last 20 years :-) -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 5:20 ` Óscar Fuentes @ 2009-11-30 6:03 ` Karl Fogel 2009-11-30 6:41 ` Óscar Fuentes ` (3 more replies) 2009-11-30 6:41 ` Stephen J. Turnbull 2009-12-01 4:10 ` Richard Stallman 2 siblings, 4 replies; 77+ messages in thread From: Karl Fogel @ 2009-11-30 6:03 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: >> > I have no problem at all deleting the document if it damages the >> > transition to Bazaar. But so far, your reasons for doing it are not >> > convincing at all to me and just demonstrates a misunderstanding of >> > the demography of Emacs and their current VC practices. >> >> On the other hand, how many VCS transitions have you managed for >> Emacs-sized projects? I've done two so far. I can say from >> experience the cost of support is not polynomial in extra workflows >> during the transition. > > Okay. Your experience trumps over my reasoning. Page deleted. > > But from now on I don't feel obliged to help supporting those who think > that they have better things to do than learning a new way of doing > something that worked fine for the last 20 years :-) Hmm. I think we have been editing simultaneously! Here's what I just did: * Removed all the alternate scenarios and stacked-branches talk from http://www.emacswiki.org/emacs/BzrForEmacsDevs, leaving just the one workflow for regular contributors. I hope this simplifies the page a lot, and makes it clear that it is intended to give a single, recommended workflow. * For those alternate scenarios, we now refer out to a new page: http://www.emacswiki.org/emacs/BzrForEmacsCasualDevs, which strongly recommends people to use the regular workflow, but describes a couple of alternate ways for those who really want that. Because it still makes it clear that we recommend the "regular contributor" workflow, I think this will not lead to confusion. * On http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs, I've moved the recommendation to try the "regular contributor" workflow (i.e., BzrForEmacsDevs) to the top, and strengthened it. Oscar, I hope that was okay, and that you feel the wording there is accurate. If not, please tweak. I did my work in the wiki instead of the mailing list only because that seemed the easiest way to communicate my edits, not because I meant them to be the final word. I think our documentation is mostly consistent and non-confusing now. We have three pages, but two of them point clearly to BzrForEmacsDevs as the recommended workflow, and that page refers out to the other two where appropriate. We can also manually point a person to either of those other two if and when that person balks at using BzrForEmacsDevs (for lack of time or whatever reason). So when we do the switchover, if we point to http://www.emacswiki.org/emacs/BzrForEmacsDevs as the place to start, that should work, and will nudge people toward adopting a dVCS way of working from the start. But those who don't want that have other options prepared for them. Does this sound sane? Continued improvements to any of the docs welcome, of course. -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 6:03 ` Karl Fogel @ 2009-11-30 6:41 ` Óscar Fuentes 2009-11-30 7:21 ` Stephen J. Turnbull ` (2 subsequent siblings) 3 siblings, 0 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-30 6:41 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel Karl Fogel <kfogel@red-bean.com> writes: [snip] >> Okay. Your experience trumps over my reasoning. Page deleted. > > Hmm. I think we have been editing simultaneously! You resuscitated the page 25 minutes after I deleted it. > Here's what I just did: > > * Removed all the alternate scenarios and stacked-branches talk from > http://www.emacswiki.org/emacs/BzrForEmacsDevs, leaving just the one > workflow for regular contributors. I hope this simplifies the page > a lot, and makes it clear that it is intended to give a single, > recommended workflow. [snip] That's good idea. The shorter the document is, the less daunting it looks. Moving alternate workflows to other page instead of deleting them was good idea too, IMHO, although I guess that deleting them would be more appropriate from Stephen's POV. > * On http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs, I've > moved the recommendation to try the "regular contributor" workflow > (i.e., BzrForEmacsDevs) to the top, and strengthened it. [snip] Your changes looks okay to me. Nevertheless, if you still think that BzrQuickStartForEmacsDevs will create more problems than solutions on the transition, go ahead and send it back to the heaven of the wiki pages. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 6:03 ` Karl Fogel 2009-11-30 6:41 ` Óscar Fuentes @ 2009-11-30 7:21 ` Stephen J. Turnbull 2009-11-30 19:27 ` Eli Zaretskii 2009-12-01 4:09 ` Richard Stallman 3 siblings, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 7:21 UTC (permalink / raw) To: Karl Fogel; +Cc: Óscar Fuentes, emacs-devel Your description sounds sane to me. I'm going to be preparing for a business trip and start of classes, so if you want me to review somethingbefore the weekend, ping me directly (I won't be looking at emacs-devel for a couple of days, starting now :-). ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 6:03 ` Karl Fogel 2009-11-30 6:41 ` Óscar Fuentes 2009-11-30 7:21 ` Stephen J. Turnbull @ 2009-11-30 19:27 ` Eli Zaretskii 2009-11-30 19:37 ` Karl Fogel 2009-12-01 1:53 ` Stephen J. Turnbull 2009-12-01 4:09 ` Richard Stallman 3 siblings, 2 replies; 77+ messages in thread From: Eli Zaretskii @ 2009-11-30 19:27 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Date: Mon, 30 Nov 2009 00:03:59 -0600 > Cc: emacs-devel@gnu.org > > Here's what I just did: Thanks. > Continued improvements to any of the docs welcome, of course. I fixed one or two factual inaccuracies and slightly improved wording in a couple of places. What's below are random stylistic and methodological comments. Feel free to do anything you want with them, including nothing at all. . The page is biased towards contributors who don't have write access to the Emacs repository. Notably, it gives almost all examples using the HTPP URL, not the SFTP one. Sometimes it mentions the SFTP method, sometimes it does not. It could be a better idea to give both variants for each command. . A Unix-like system is assumed without any notice to that effect. Some commands will not work on Windows without subtle changes. For example, echo "public_branch = http://bzr.savannah.gnu.org/r/emacs/trunk" >> .bzr/branch/branch.conf will not do what you mean with the `echo' that it built into the Windows shell. Maybe someone could add footnotes with Windows equivalents, where applicable (in this case, either remove the quotes or use the ported GNU `echo'). . The single-level sectioning is not the best one in this case, because the page actually has 5 top-level sections, which I would call Intro, Getting Started, One-Off Change, Feature Branch, Resources; and some of these have sub-sections. Presenting them as a single-level document makes it harder to grasp the outline of the narrative. Suggest to have 2 levels of sections, not one. . The "Overview of the Bazaar work routine" is too detailed, IMO, and thus unnecessarily longish. We will be explaining all the details in a moment, so I think only the main points should be left in this overview. . "Other Resources" should be at the beginning. Someone who looks for a CVS-like way of doing things should not be required to read through such a long document to find the alternatives near the end. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 19:27 ` Eli Zaretskii @ 2009-11-30 19:37 ` Karl Fogel 2009-11-30 20:36 ` Eli Zaretskii 2009-12-01 1:53 ` Stephen J. Turnbull 1 sibling, 1 reply; 77+ messages in thread From: Karl Fogel @ 2009-11-30 19:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Continued improvements to any of the docs welcome, of course. > > I fixed one or two factual inaccuracies and slightly improved wording > in a couple of places. Thank you! > What's below are random stylistic and methodological comments. Feel > free to do anything you want with them, including nothing at all. > > . The page is biased towards contributors who don't have write access > to the Emacs repository. Notably, it gives almost all examples > using the HTPP URL, not the SFTP one. Sometimes it mentions the > SFTP method, sometimes it does not. It could be a better idea to > give both variants for each command. Hmmm. Good point -- I'll take a look and see what I can do. If anything, it should be biased toward SFTP and mention HTTP as an alternate method. > . A Unix-like system is assumed without any notice to that effect. > Some commands will not work on Windows without subtle changes. For > example, > > echo "public_branch = http://bzr.savannah.gnu.org/r/emacs/trunk" >> .bzr/branch/branch.conf > > will not do what you mean with the `echo' that it built into the > Windows shell. Maybe someone could add footnotes with Windows > equivalents, where applicable (in this case, either remove the > quotes or use the ported GNU `echo'). Also a good point. I haven't used Windows for almost 18 years now, so I'll just put in notes that it's Unix-centric. > . The single-level sectioning is not the best one in this case, > because the page actually has 5 top-level sections, which I would > call Intro, Getting Started, One-Off Change, Feature Branch, > Resources; and some of these have sub-sections. Presenting them as > a single-level document makes it harder to grasp the outline of the > narrative. Suggest to have 2 levels of sections, not one. I can do that (is there any reason you didn't just make the change, though?). > . The "Overview of the Bazaar work routine" is too detailed, IMO, and > thus unnecessarily longish. We will be explaining all the details > in a moment, so I think only the main points should be left in this > overview. Will take a look and adjust accordingly. > . "Other Resources" should be at the beginning. Someone who looks > for a CVS-like way of doing things should not be required to read > through such a long document to find the alternatives near the end. I was already planning to move the "quick start" links to the beginning, along with some explanation. The other other resources can stay where they are, I think. Thanks for the review, Eli. -K ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 19:37 ` Karl Fogel @ 2009-11-30 20:36 ` Eli Zaretskii 2009-11-30 21:06 ` Karl Fogel 0 siblings, 1 reply; 77+ messages in thread From: Eli Zaretskii @ 2009-11-30 20:36 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, emacs-devel > From: Karl Fogel <karl.fogel@canonical.com> > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > Date: Mon, 30 Nov 2009 13:37:06 -0600 > > is there any reason you didn't just make the change, though? These are largely a matter of methodology: how to present this subject to Emacs developers. With all the differences of opinions on issues like this between myself and almost everybody else that we've seen lately here, I lost confidence that such changes will be welcome. > > . "Other Resources" should be at the beginning. Someone who looks > > for a CVS-like way of doing things should not be required to read > > through such a long document to find the alternatives near the end. > > I was already planning to move the "quick start" links to the beginning, > along with some explanation. The other other resources can stay where > they are, I think. In that case, at least mention right at the beginning that whoever looks for something like that will find it near the end. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 20:36 ` Eli Zaretskii @ 2009-11-30 21:06 ` Karl Fogel 0 siblings, 0 replies; 77+ messages in thread From: Karl Fogel @ 2009-11-30 21:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> is there any reason you didn't just make the change, though? > > These are largely a matter of methodology: how to present this subject > to Emacs developers. With all the differences of opinions on issues > like this between myself and almost everybody else that we've seen > lately here, I lost confidence that such changes will be welcome. Oh, those differences have all been about what overall direction to recommend to developers, which is a larger issue that's not really about any individual document's structure. AFAIK, everyone has welcomed organizational edits made to any page -- certainly I have, and so have Óscar and Stephen. Please don't be afraid to edit. (But I'll take care of this one, since I'm already doing other stuff on the page.) -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 19:27 ` Eli Zaretskii 2009-11-30 19:37 ` Karl Fogel @ 2009-12-01 1:53 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-12-01 1:53 UTC (permalink / raw) To: rms; +Cc: Karl Fogel, Eli Zaretskii, emacs-devel Eli Zaretskii writes: > . The page is biased towards contributors who don't have write access > to the Emacs repository. Notably, it gives almost all examples > using the HTPP URL, not the SFTP one. That's right, but the reason I left it that way was not "committers" vs. "others". It's "URLs we are almost sure will work" vs. "URLS we hope will be replaced by much better schemes". If at all possible, we want the SFTP URL to be replaced by bzr+ssh, but that does not work at all right now. My logic is that as it stands, the reader who doesn't remember the committer URL must go back to the beginning, where she will see the warning about possibly changing URLs. @RMS: Is there no chance that you will intervene and ask the Savannah admins to increase the priority of bzr+ssh? This is extremely important to the uptake of Bazaar on Savannah. With dumb transports like HTTP and SFTP, frequently network transfers of 25MB have been observed in the process of committing a tiny (~10 lines) patch, because a whole pack (essentially, a zip file full of diffs representing revisions) gets transferred from the local system to the upstream master. With a bzr server, only the diff need be sent, and the pack is rewritten on the upstream master's host. This affects all committer workflows, and IIRC locks the repository so that other committers cannot write (AFAIK it's still readable, but of course readers will get stale data). But the concerns of the Savannah hackers are valid. Although discussion on bazaar@canonical.com indicates that their security analysis is incorrect, they must convince themselves that is true, and that is not costless. Only you have the stature to increase the priority of that work. > . A Unix-like system is assumed without any notice to that effect. > Some commands will not work on Windows without subtle changes. For > example, > > echo "public_branch = http://bzr.savannah.gnu.org/r/emacs/trunk" >> .bzr/branch/branch.conf In this particular case AFAIK you don't need the quotes on Unix either. > . "Other Resources" should be at the beginning. Someone who looks > for a CVS-like way of doing things should not be required to read > through such a long document to find the alternatives near the end. You are welcome to edit it that way if you want. I believe you would certainly have RMS's support in doing that. I'm not going to play "last patch wins" if you do, and I don't think Karl will either. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 6:03 ` Karl Fogel ` (2 preceding siblings ...) 2009-11-30 19:27 ` Eli Zaretskii @ 2009-12-01 4:09 ` Richard Stallman 3 siblings, 0 replies; 77+ messages in thread From: Richard Stallman @ 2009-12-01 4:09 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, emacs-devel * On http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs, I've moved the recommendation to try the "regular contributor" workflow (i.e., BzrForEmacsDevs) to the top, and strengthened it. You are pushing too hard for people to use the more complex dVCS workflow. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 5:20 ` Óscar Fuentes 2009-11-30 6:03 ` Karl Fogel @ 2009-11-30 6:41 ` Stephen J. Turnbull 2009-11-30 7:02 ` Óscar Fuentes 2009-12-01 4:10 ` Richard Stallman 2 siblings, 1 reply; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 6:41 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > > On the other hand, how many VCS transitions have you managed for > > Emacs-sized projects? I've done two so far. I can say from > > experience the cost of support is not polynomial in extra workflows > > during the transition. > > Okay. Your experience trumps over my reasoning. Page deleted. I'm going to keep a copy (unless my browser has crashed in the meantime ;-) and integrate some of it into the section of our page on stacked branches. Is that OK with you? > But from now on I don't feel obliged to help supporting those who think > that they have better things to do than learning a new way of doing > something that worked fine for the last 20 years :-) That's exactly how Karl and I reason, but with a somewhat different conclusion. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 6:41 ` Stephen J. Turnbull @ 2009-11-30 7:02 ` Óscar Fuentes 2009-11-30 9:17 ` Stephen J. Turnbull 0 siblings, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-11-30 7:02 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > > > On the other hand, how many VCS transitions have you managed for > > > Emacs-sized projects? I've done two so far. I can say from > > > experience the cost of support is not polynomial in extra workflows > > > during the transition. > > > > Okay. Your experience trumps over my reasoning. Page deleted. > > I'm going to keep a copy (unless my browser has crashed in the > meantime ;-) and integrate some of it into the section of our page on > stacked branches. Is that OK with you? It seems contradictory to point out the cost of support associated to having several workflows and then reintroduce one workflow when the author deleted it for alleviating the problem. Karl recovered the page and made some editions to it. Please see my response to him and reconsider your above suggestion in the light of the new state of the documentation. [snip] -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 7:02 ` Óscar Fuentes @ 2009-11-30 9:17 ` Stephen J. Turnbull 2009-11-30 14:35 ` Karl Fogel 2009-11-30 15:31 ` Óscar Fuentes 0 siblings, 2 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 9:17 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > It seems contradictory to point out the cost of support associated to > having several workflows and then reintroduce one workflow when the > author deleted it for alleviating the problem. It would be if (a) Karl and I were the same person and (b) the wiki reported conflicts. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 9:17 ` Stephen J. Turnbull @ 2009-11-30 14:35 ` Karl Fogel 2009-11-30 15:31 ` Óscar Fuentes 1 sibling, 0 replies; 77+ messages in thread From: Karl Fogel @ 2009-11-30 14:35 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > It seems contradictory to point out the cost of support associated to > > having several workflows and then reintroduce one workflow when the > > author deleted it for alleviating the problem. > > It would be if (a) Karl and I were the same person and (b) the wiki > reported conflicts. Yes. I had no awareness I was "recovering" the page -- I never knew that it had been deleted! :-) My editing session on that page started before the deletion. But I don't regret having revived it, now that it makes clear that we recommend a more dVCS-ish way, and that BzrForEmacsDevs is a superset of it. As Glenn Morris and a couple of others have requested that it stay around, I certainly won't delete it. The main thing is to provide clear directions for those coming in with no prior opinion. People who already know they prefer the quick-start guide are best served by getting one -- for me, the only question was how to provide that to them *without* confusing anyone else, and I think we've found a way to do that. -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 9:17 ` Stephen J. Turnbull 2009-11-30 14:35 ` Karl Fogel @ 2009-11-30 15:31 ` Óscar Fuentes 2009-11-30 17:40 ` Stephen J. Turnbull 1 sibling, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-11-30 15:31 UTC (permalink / raw) To: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > > It seems contradictory to point out the cost of support associated to > > having several workflows and then reintroduce one workflow when the > > author deleted it for alleviating the problem. > > It would be if (a) Karl and I were the same person and (b) the wiki > reported conflicts. Karl's action has nothing to do here. Wasn't it clear on the quoted text? I was talking about you: > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > Óscar Fuentes writes: > > > "Stephen J. Turnbull" <stephen@xemacs.org> writes: > > > On the other hand, how many VCS transitions have you managed for > > > Emacs-sized projects? I've done two so far. I can say from > > > experience the cost of support is not polynomial in extra workflows > > > during the transition. > > > > Okay. Your experience trumps over my reasoning. Page deleted. > > I'm going to keep a copy (unless my browser has crashed in the > meantime ;-) and integrate some of it into the section of our page on > stacked branches. Is that OK with you? -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 15:31 ` Óscar Fuentes @ 2009-11-30 17:40 ` Stephen J. Turnbull 2009-11-30 18:02 ` Óscar Fuentes 2009-11-30 19:21 ` Karl Fogel 0 siblings, 2 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-11-30 17:40 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > Karl's action has nothing to do here. Wasn't it clear on the quoted > text? I was talking about you: Reread the thread. Since you insisted on keeping your page, IIRC I've said nothing since about deleting that page, and in fact have added references to it from the main page on the assumption it was going to stay. It was Karl who asked you to delete it more recently. True I supported his argument that having too many workflows can be confusing against your claim that it won't be, but that doesn't mean that I supported his request to delete the page. Especially since RMS clearly wants to keep it, and even make it the recommended workflow -- and if things go that way, there's no point in paying attention to me 'cause I'll be gone. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 17:40 ` Stephen J. Turnbull @ 2009-11-30 18:02 ` Óscar Fuentes 2009-12-01 1:21 ` Stephen J. Turnbull 2009-11-30 19:21 ` Karl Fogel 1 sibling, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-11-30 18:02 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > > Karl's action has nothing to do here. Wasn't it clear on the quoted > > text? I was talking about you: > > Reread the thread. The sequence of events that raised this subthread was: Karl: It would be a good thing if you delete the page. Oscar: I think that the page will reduce the amount of support that emacs hackers will need on the transition. Stephen: My experience says that having multiple workflows increases the support load significantly. Oscar: Okay, then I'll delete the page (so there is one less workflow to care about) Stephen: I'll like to put back that workflow on the available documentation. So you said that having multiple workflows increases the burden, then I remove one workflow and you propose to add it back to the documentation. That's what I find contradictory. It is just that the pedantic maths freak in me can't resist pointing out logical inconsistencies :-) [snip] -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 18:02 ` Óscar Fuentes @ 2009-12-01 1:21 ` Stephen J. Turnbull 0 siblings, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-12-01 1:21 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > Stephen: I'll like to put back that workflow on the available > documentation. You're misrepresenting what I wrote. Please don't do that. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 17:40 ` Stephen J. Turnbull 2009-11-30 18:02 ` Óscar Fuentes @ 2009-11-30 19:21 ` Karl Fogel 1 sibling, 0 replies; 77+ messages in thread From: Karl Fogel @ 2009-11-30 19:21 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > Karl's action has nothing to do here. Wasn't it clear on the quoted > > text? I was talking about you: > > Reread the thread. Since you insisted on keeping your page, IIRC I've > said nothing since about deleting that page, and in fact have added > references to it from the main page on the assumption it was going to > stay. It was Karl who asked you to delete it more recently. > > True I supported his argument that having too many workflows can be > confusing against your claim that it won't be, but that doesn't mean > that I supported his request to delete the page. Especially since RMS > clearly wants to keep it, and even make it the recommended workflow -- > and if things go that way, there's no point in paying attention to me > 'cause I'll be gone. Heh. I'll volunteer to have been inconsistent with something I previously said, if it will stop this particular subthread :-). Anyway, the thing that upsets people about too many choices is being ill-equipped to deal with them. So rather than delete workflow documentation that some people (RMS, Glenn Morris, et al) find useful, I think a strategy of being clear about - our recommended entry point (for those who need one), and - what each piece of documentation is for, and - how it relates to the others is best. That default entry point should be BzrForEmacsDevs, IMHO. I think we're close to switching now; it depends on the pretest schedule, which I'm not following. I'll post separately about that. -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-30 5:20 ` Óscar Fuentes 2009-11-30 6:03 ` Karl Fogel 2009-11-30 6:41 ` Stephen J. Turnbull @ 2009-12-01 4:10 ` Richard Stallman 2009-12-01 6:21 ` Óscar Fuentes 2 siblings, 1 reply; 77+ messages in thread From: Richard Stallman @ 2009-12-01 4:10 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Okay. Your experience trumps over my reasoning. Page deleted. What page did you delete? I hope it was not your intro to simple use of Bzr. I saved a copy; if necessary I will republish it. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 4:10 ` Richard Stallman @ 2009-12-01 6:21 ` Óscar Fuentes 2009-12-01 6:52 ` Karl Fogel 2009-12-02 7:32 ` Richard Stallman 0 siblings, 2 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-12-01 6:21 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > Okay. Your experience trumps over my reasoning. Page deleted. > > What page did you delete? I hope it was not your intro to simple use > of Bzr. I saved a copy; if necessary I will republish it. The page was restored by Karl Fogel some minutes later with a note at the beginning encouraging the reader to try the distributed workflow. I'm not against recommending the distributed workflow. Actually, the workflow that I use for my work is far more complex than the distributed one recommended by Karl. What I find puzzling is the hostility towards the centralized workflow described on BzrQuickStartForEmacsDevs. It is a correct practice, which Bazaar proudly advertises as one of its multiple supported workflows. In the context of Emacs, every developer can use the distributed workflow, the centralized one or even switch between them at any time without causing harm to the project or inconveniencing other developers, as far as he follows some simple rules when he sends his changes upstream. I have the impression that some people thinks that having developers not using a distributed workflow since day one would signal a failed transition, or a failure of Bazaar itself adapting to the project. Quite the contrary: the fact that Bazaar supports multiple compatible workflows allowing each user to choose whatever suits him better is, possibly, the best selling point for Bazaar. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 6:21 ` Óscar Fuentes @ 2009-12-01 6:52 ` Karl Fogel 2009-12-01 8:34 ` Jason Rumney 2009-12-02 7:32 ` Richard Stallman 1 sibling, 1 reply; 77+ messages in thread From: Karl Fogel @ 2009-12-01 6:52 UTC (permalink / raw) To: Óscar Fuentes; +Cc: rms, emacs-devel On Tue, Dec 1, 2009 at 1:21 AM, Óscar Fuentes <ofv@wanadoo.es> wrote: > I'm not against recommending the distributed workflow. Actually, the > workflow that I use for my work is far more complex than the distributed > one recommended by Karl. What I find puzzling is the hostility towards > the centralized workflow described on BzrQuickStartForEmacsDevs. It is a > correct practice, which Bazaar proudly advertises as one of its multiple > supported workflows. In the context of Emacs, every developer can use > the distributed workflow, the centralized one or even switch between > them at any time without causing harm to the project or inconveniencing > other developers, as far as he follows some simple rules when he sends > his changes upstream. > > I have the impression that some people thinks that having developers not > using a distributed workflow since day one would signal a failed > transition, or a failure of Bazaar itself adapting to the project. Quite > the contrary: the fact that Bazaar supports multiple compatible > workflows allowing each user to choose whatever suits him better is, > possibly, the best selling point for Bazaar. Sorry, if I ever gave that impression, I didn't mean to. I don't think there's anything objectively wrong with someone choosing the non-distributed workflow. My concern is simply that the Emacs project be able to clearly and unambiguously answer the question "How do I hack on Emacs?" The answer to that question *cannot* be "First go learn all the different ways you can use Bazaar, then pick one, set yourself up, and start coding." That would be a hackability nightmare for contributors, and a support nightmare for the project. The multiplicity of workflows available in Bazaar has not, historically, been a selling point, much as we might theorize it is. Instead, the richness of the tool tends to confuse users -- even sophisticated users, sometimes. (The Bazaar project realizes this and is working to fix it.) Stephen and I have worked on distributed projects using Bazaar before, and both find that the workflow described in BzrForEmacsDevs strikes a decent balance between ease of learning and suitability for the Emacs project. Therefore, we want to hand it out as the *default* answer for the question "How do I hack on Emacs?" That doesn't mean it's the only way. But I can tell you right now (having experienced *exactly this phenomenon* in other projects) that if every time someone posts asking how to get involved now that Emacs is in Bazaar, they get several different and seemingly inconsistent answers, their hacking energy will be quickly depleted. We've been there. We've seen it. I'll consider it both a personal and a systemic failure if this project fails to take advantage of this highly relevant experience accumulated by (at least) two of its participants :-). ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 6:52 ` Karl Fogel @ 2009-12-01 8:34 ` Jason Rumney 2009-12-01 15:26 ` Karl Fogel 0 siblings, 1 reply; 77+ messages in thread From: Jason Rumney @ 2009-12-01 8:34 UTC (permalink / raw) To: Karl Fogel; +Cc: Óscar Fuentes, rms, emacs-devel Karl Fogel wrote: > I don't think there's anything objectively wrong with someone > choosing the non-distributed workflow. My concern is simply that > the Emacs project be able to clearly and unambiguously answer > the question "How do I hack on Emacs?" > While the distributed workflow might be a better approach for people starting with a clean slate, existing developers (and users who track CVS) do not necessarily have the time to invest in learning a new workflow immediately, and are looking for minimum disruption immediately after the switch from CVS to bzr. So there is definite value in an additional document describing a quick and painless transition from CVS, and probably a migration path to the distributed workflow for when the developer has time to adjust their habits. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 8:34 ` Jason Rumney @ 2009-12-01 15:26 ` Karl Fogel 2009-12-01 19:03 ` Eli Zaretskii 0 siblings, 1 reply; 77+ messages in thread From: Karl Fogel @ 2009-12-01 15:26 UTC (permalink / raw) To: Jason Rumney; +Cc: Óscar Fuentes, rms, emacs-devel On Tue, Dec 1, 2009 at 3:34 AM, Jason Rumney <jasonr@gnu.org> wrote: > Karl Fogel wrote: >> >> I don't think there's anything objectively wrong with someone >> choosing the non-distributed workflow. My concern is simply that >> the Emacs project be able to clearly and unambiguously answer >> the question "How do I hack on Emacs?" > > While the distributed workflow might be a better approach for people > starting with a clean slate, existing developers (and users who track CVS) > do not necessarily have the time to invest in learning a new workflow > immediately, and are looking for minimum disruption immediately after the > switch from CVS to bzr. So there is definite value in an additional document > describing a quick and painless transition from CVS, and probably a > migration path to the distributed workflow for when the developer has time > to adjust their habits. Absolutely. We already have the additional document, and it is prominently linked to, so no problems there. I myself don't know how to document the migration path from there to the distributed workflow, but I hope that someone who does will do so. -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 15:26 ` Karl Fogel @ 2009-12-01 19:03 ` Eli Zaretskii 2009-12-01 19:56 ` Jason Earl ` (2 more replies) 0 siblings, 3 replies; 77+ messages in thread From: Eli Zaretskii @ 2009-12-01 19:03 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, emacs-devel > Date: Tue, 1 Dec 2009 10:26:02 -0500 > From: Karl Fogel <kfogel@red-bean.com> > Cc: =?ISO-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es>, rms@gnu.org, > emacs-devel@gnu.org > > > While the distributed workflow might be a better approach for people > > starting with a clean slate, existing developers (and users who track CVS) > > do not necessarily have the time to invest in learning a new workflow > > immediately, and are looking for minimum disruption immediately after the > > switch from CVS to bzr. So there is definite value in an additional document > > describing a quick and painless transition from CVS, and probably a > > migration path to the distributed workflow for when the developer has time > > to adjust their habits. > > Absolutely. We already have the additional document, and it is > prominently linked to, so no problems there. So, as long as we all think that the "Quick Start" page will be useful to some, here are a comment about it: The setup and workflow described by this page is advertised (by its parent "Bzr For Emacs Devs") as ``CVS-like''. But this isn't really accurate, is it? The command shown to checkout the trunk is this: bzr checkout URL_TO_UPSTREAM_TRUNK trunk However, IIUC, the slightly modified checkout command bzr checkout --lightweight URL_TO_UPSTREAM_TRUNK trunk is a closer equivalent of the CVS checkout, because it only checks out the working tree without creating a full local copy of history. The history is only needed if one wants to commit locally. People who don't plan on using local commits don't need to pay the extra price of larger disk storage and probably also some additional time it takes to do a heavyweight checkout. OTOH, if we think that a heavyweight checkout is the recommended way, then we should at least mention its main benefit -- the local commit. Currently, the page only hints on that, but stops short of showing the commands to use this potential: You have in your disk a copy of the VC history of the trunk branch since the last bzr update. Hence, Bazaar does not need to contact a server upstream for displaying logs, reverting edited files, annotating, etc. This is useful for working off-line. Bazaar makes possible to commit changes off-line to your local history and send them upstream in one batch. Personally, I would do both: tell about --lightweight as the equivalent of CVS, and also tell about the local commits available with the heavyweight checkouts. But that's me. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 19:03 ` Eli Zaretskii @ 2009-12-01 19:56 ` Jason Earl 2009-12-01 20:21 ` Eli Zaretskii 2009-12-02 7:33 ` Richard Stallman 2009-12-01 21:44 ` Óscar Fuentes 2009-12-01 21:53 ` Stefan Monnier 2 siblings, 2 replies; 77+ messages in thread From: Jason Earl @ 2009-12-01 19:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, ofv, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Tue, 1 Dec 2009 10:26:02 -0500 >> From: Karl Fogel <kfogel@red-bean.com> >> Cc: =?ISO-8859-1?Q?=D3scar_Fuentes?= <ofv@wanadoo.es>, rms@gnu.org, >> emacs-devel@gnu.org >> >> > While the distributed workflow might be a better approach for >> > people starting with a clean slate, existing developers (and users >> > who track CVS) do not necessarily have the time to invest in >> > learning a new workflow immediately, and are looking for minimum >> > disruption immediately after the switch from CVS to bzr. So there >> > is definite value in an additional document describing a quick and >> > painless transition from CVS, and probably a migration path to the >> > distributed workflow for when the developer has time to adjust >> > their habits. >> >> Absolutely. We already have the additional document, and it is >> prominently linked to, so no problems there. > > So, as long as we all think that the "Quick Start" page will be useful > to some, here are a comment about it: > > The setup and workflow described by this page is advertised (by its > parent "Bzr For Emacs Devs") as ``CVS-like''. But this isn't really > accurate, is it? The command shown to checkout the trunk is this: > > bzr checkout URL_TO_UPSTREAM_TRUNK trunk > > However, IIUC, the slightly modified checkout command > > bzr checkout --lightweight URL_TO_UPSTREAM_TRUNK trunk I *really* don't think that you want to advertise lightweight checkouts that point to non-local URLs. > is a closer equivalent of the CVS checkout, because it only checks out > the working tree without creating a full local copy of history. The > history is only needed if one wants to commit locally. People who > don't plan on using local commits don't need to pay the extra price of > larger disk storage and probably also some additional time it takes to > do a heavyweight checkout. The history is also needed if you want to do any sort of bzr command, like bzr log or bzr annotate. Heck, even bzr status requires access to the parent branch. Even if you don't want to commit locally (and with a checkout you probably *don't* want to commit locally), it is still worthwhile to have the branch history on a local disk. Using a lightweight checkout might be a net win for people who are simply interested in following Emacs development if the lightweight checkout required less time to checkout or if it required you to download less information, but that's simply not the case with the plain jane http transport (I do not know if the smart server is an improvement either, not that it matters as it appears that Savannah is not going to provide one). bzr checkouts *work* like cvs checkouts, you don't even need a fancy bzr repository. The primary difference is that they still work when disconnected from the network. Well, that and with bzr you can rename files, and commits are atomic, and bzr is actively maintained, etc. > OTOH, if we think that a heavyweight checkout is the recommended way, > then we should at least mention its main benefit -- the local commit. > Currently, the page only hints on that, but stops short of showing the > commands to use this potential: > > You have in your disk a copy of the VC history of the trunk branch > since the last bzr update. Hence, Bazaar does not need to contact a > server upstream for displaying logs, reverting edited files, > annotating, etc. This is useful for working off-line. > > Bazaar makes possible to commit changes off-line to your local > history and send them upstream in one batch. > > Personally, I would do both: tell about --lightweight as the > equivalent of CVS, and also tell about the local commits available > with the heavyweight checkouts. But that's me. At some point we need to point people at the existing Bazaar documentation. I personally don't have a problem with CVS-style usage of Bazaar. In fact, one of the reasons that I like bzr is that it allows for this type of usage in situations where it makes sense. However, a lightweight checkout of a non-local branch is a real loser performance wise, and it throws away many of the advantages that bzr has over CVS. The entire history of the mainline of Emacs can be compressed into just under 200M. The entire history of all of the branches of Emacs is about 10% more than that. I just don't think that lightweight checkouts is something that we want to advertise. Jason ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 19:56 ` Jason Earl @ 2009-12-01 20:21 ` Eli Zaretskii 2009-12-02 1:28 ` Stefan Monnier 2009-12-02 2:07 ` Stephen J. Turnbull 2009-12-02 7:33 ` Richard Stallman 1 sibling, 2 replies; 77+ messages in thread From: Eli Zaretskii @ 2009-12-01 20:21 UTC (permalink / raw) To: Jason Earl; +Cc: kfogel, ofv, emacs-devel > From: Jason Earl <jearl@notengoamigos.org> > Cc: Karl Fogel <kfogel@red-bean.com>, ofv@wanadoo.es, emacs-devel@gnu.org > Date: Tue, 01 Dec 2009 12:56:26 -0700 > > The history is also needed if you want to do any sort of bzr command, > like bzr log or bzr annotate. As you well know, these go upstream in CVS as well. So this is not really a loss for people who want a familiar CVS-like setup. > At some point we need to point people at the existing Bazaar > documentation. After reading through all of it, I think it's not organized well for a single reading. I needed to read both manuals several times before it started making sense. Showing one option (--lightweight) and one command (commit --local) is hardly worth sending people to wade through the canonical docs, just to find that it, too, says that a lightweight checkout is almost like CVS. Anyway, that's my last post on this issue. I hope my opinions on this are clear enough. I don't think I will use the CVS-like setup, but I see no reason not to help those who will. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 20:21 ` Eli Zaretskii @ 2009-12-02 1:28 ` Stefan Monnier 2009-12-02 7:20 ` Eli Zaretskii 2009-12-02 2:07 ` Stephen J. Turnbull 1 sibling, 1 reply; 77+ messages in thread From: Stefan Monnier @ 2009-12-02 1:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kfogel, ofv, Jason Earl, emacs-devel >> The history is also needed if you want to do any sort of bzr command, >> like bzr log or bzr annotate. > As you well know, these go upstream in CVS as well. So this is not > really a loss for people who want a familiar CVS-like setup. The performance will usually be significantly worse than with CVS. E.g. if you do a "bzr log", it's likely that a lightweight checkout accessing a remote repository over sftp will end up transfering the entire history (e.g. 200MB for Emacs) over the network. If you can access the repository over bzr+ssh, it might be a lot better (a lot closer to cvs), but it's still likely to be slower than cvs, if for nothing else that it's a discouraged usage. Stefan ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 1:28 ` Stefan Monnier @ 2009-12-02 7:20 ` Eli Zaretskii 2009-12-02 14:42 ` Stefan Monnier 0 siblings, 1 reply; 77+ messages in thread From: Eli Zaretskii @ 2009-12-02 7:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: kfogel, ofv, jearl, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Jason Earl <jearl@notengoamigos.org>, kfogel@red-bean.com, ofv@wanadoo.es, emacs-devel@gnu.org > Date: Tue, 01 Dec 2009 20:28:22 -0500 > > >> The history is also needed if you want to do any sort of bzr command, > >> like bzr log or bzr annotate. > > As you well know, these go upstream in CVS as well. So this is not > > really a loss for people who want a familiar CVS-like setup. > > The performance will usually be significantly worse than with CVS. Yes, it's slow. "bzr annotate" in a lightweight checkout takes almost 3 minutes here. What's worse, it seems to send the entire annotated source downstream in one big chunk, whereas CVS seemed to send it in smaller chunks, so if you pipe the output to a pager, as you normally would, with CVS you could begin reading before the whole file was received. (With a local branch, "bzr annotate" takes about 30 seconds, not exactly the speed of light, either.) "bzr log" takes about a minute for a lightweight checkout vs 10 seconds for a local branch. So I guess if you use annotate and log a lot, then lightweight checkouts are not for you. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 7:20 ` Eli Zaretskii @ 2009-12-02 14:42 ` Stefan Monnier 2009-12-02 15:59 ` Karl Fogel 2009-12-02 18:29 ` Óscar Fuentes 0 siblings, 2 replies; 77+ messages in thread From: Stefan Monnier @ 2009-12-02 14:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kfogel, ofv, jearl, emacs-devel > Yes, it's slow. "bzr annotate" in a lightweight checkout takes almost > 3 minutes here. What's worse, it seems to send the entire annotated > source downstream in one big chunk, whereas CVS seemed to send it in Remember that the network protocol used is sftp, so the remote repository is "dumb" and cannot perform any operation such as "annotate". So when you do an "annotate", nothing is sent upstream other than commands to fetch files that contain the relevant parts of history, and then the annotate operation is performed locally. > received. (With a local branch, "bzr annotate" takes about 30 > seconds, not exactly the speed of light, either.) Yes, it's a fairly slow operation, sadly. I encourage you to complain to the Bazaar developers about it, Stefan ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 14:42 ` Stefan Monnier @ 2009-12-02 15:59 ` Karl Fogel 2009-12-02 17:44 ` Eli Zaretskii 2009-12-02 18:40 ` Óscar Fuentes 2009-12-02 18:29 ` Óscar Fuentes 1 sibling, 2 replies; 77+ messages in thread From: Karl Fogel @ 2009-12-02 15:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: ofv, Eli Zaretskii, jearl, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Yes, it's slow. "bzr annotate" in a lightweight checkout takes almost >> 3 minutes here. What's worse, it seems to send the entire annotated >> source downstream in one big chunk, whereas CVS seemed to send it in > > Remember that the network protocol used is sftp, so the remote > repository is "dumb" and cannot perform any operation such as > "annotate". So when you do an "annotate", nothing is sent upstream > other than commands to fetch files that contain the relevant parts of > history, and then the annotate operation is performed locally. I'm hoping we can change that soon, with bzr+ssh access. See https://savannah.gnu.org/support/?107077 for details. In related matters, I'm hoping we can get Bazaar 2.0.2 on Savannah. https://lists.ubuntu.com/archives/bazaar/2009q4/064932.html quotes Norbert Tretkowski as saying he has uploaded a bzr 2.0.2 lenny backport to http://people.debian.org/~nobse/temp/bzr/, and that he'll upload it to backports.org soon. http://packages.debian.org/lenny-backports/bzr doesn't have it yet, but I'm asking another uploader in IRC about it right now (Jelmer Vernooij). Transcript below. -Karl <kfogel> jelmer: have you seen https://lists.ubuntu.com/archives/bazaar/2009q4/064932.html? Apparently Norbert Tretkowski has uploaded a bzr 2.0.2 lenny backport to http://people.debian.org/~nobse/temp/bzr/. He said he was going to upload it to backports.org, but I don't see it at http://packages.debian.org/lenny-backports/bzr. Is this something you can do? (It would help us for the Emacs switchover.) <jelmer> kfogel: I am able to upload, but we should probably check with him <kfogel> jelmer: I don't know him, and his email address doesn't appear to be in that mail, but do you know how to contact him? I can try to track him down if not. <jelmer> kfogel, his email address is nobse at debian.org <jelmer> he is also here on IRC as nobse <jelmer> If you haven't asked him about the backports yet, I'm happy to talk to him <kfogel> jelmer: I haven't talked to him about it yet. If you can coordinate with him, that'd be great. As soon as it's on backports, we'll ask the savannah.gnu.org admins to install it [...] ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 15:59 ` Karl Fogel @ 2009-12-02 17:44 ` Eli Zaretskii 2009-12-02 18:16 ` Karl Fogel 2009-12-02 18:40 ` Óscar Fuentes 1 sibling, 1 reply; 77+ messages in thread From: Eli Zaretskii @ 2009-12-02 17:44 UTC (permalink / raw) To: Karl Fogel, Richard Stallman; +Cc: emacs-devel, monnier, jearl > From: Karl Fogel <kfogel@red-bean.com> > Cc: Eli Zaretskii <eliz@gnu.org>, jearl@notengoamigos.org, ofv@wanadoo.es, emacs-devel@gnu.org > Date: Wed, 02 Dec 2009 10:59:01 -0500 > > In related matters, I'm hoping we can get Bazaar 2.0.2 on Savannah. What about fencepost? I wrote to sysadmins asking for that (they have v1.2.0!) a week ago, but there was no response, and the version is still 1.2.0. Richard, can you perhaps speed it up? I dod almost all of my bidi development on fencepost, so that's where I need bzr first and foremost when we switch. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 17:44 ` Eli Zaretskii @ 2009-12-02 18:16 ` Karl Fogel 2009-12-02 18:20 ` Eli Zaretskii 2009-12-03 12:22 ` Richard Stallman 0 siblings, 2 replies; 77+ messages in thread From: Karl Fogel @ 2009-12-02 18:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: jearl, emacs-devel, Richard Stallman, monnier Eli Zaretskii <eliz@gnu.org> writes: >> In related matters, I'm hoping we can get Bazaar 2.0.2 on Savannah. > > What about fencepost? I wrote to sysadmins asking for that (they have > v1.2.0!) a week ago, but there was no response, and the version is > still 1.2.0. > > Richard, can you perhaps speed it up? I dod almost all of my bidi > development on fencepost, so that's where I need bzr first and > foremost when we switch. For those of us who aren't normally affected by these things: What is the difference between fencepost and savannah? Are there any other hosts we should be thinking about? (The usual Internet searches do not provide a clear answer.) Thanks, -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 18:16 ` Karl Fogel @ 2009-12-02 18:20 ` Eli Zaretskii 2009-12-03 12:22 ` Richard Stallman 1 sibling, 0 replies; 77+ messages in thread From: Eli Zaretskii @ 2009-12-02 18:20 UTC (permalink / raw) To: Karl Fogel; +Cc: jearl, emacs-devel, rms, monnier > From: Karl Fogel <kfogel@red-bean.com> > Cc: Richard Stallman <rms@gnu.org>, monnier@iro.umontreal.ca, jearl@notengoamigos.org, emacs-devel@gnu.org > Date: Wed, 02 Dec 2009 13:16:41 -0500 > > What is the difference between fencepost and savannah? All I know is that fencepost.gnu.org is the GNU Project shell server, i.e. that's where you get a shell account from the GNU Project. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 18:16 ` Karl Fogel 2009-12-02 18:20 ` Eli Zaretskii @ 2009-12-03 12:22 ` Richard Stallman 2009-12-03 15:32 ` Eli Zaretskii 2009-12-03 17:44 ` Karl Fogel 1 sibling, 2 replies; 77+ messages in thread From: Richard Stallman @ 2009-12-03 12:22 UTC (permalink / raw) To: Karl Fogel; +Cc: eliz, emacs-devel, monnier, jearl I will ping the sysadmins about updating bzr on fencepost. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-03 12:22 ` Richard Stallman @ 2009-12-03 15:32 ` Eli Zaretskii 2009-12-03 17:44 ` Karl Fogel 1 sibling, 0 replies; 77+ messages in thread From: Eli Zaretskii @ 2009-12-03 15:32 UTC (permalink / raw) To: rms; +Cc: kfogel, emacs-devel, monnier, jearl > From: Richard Stallman <rms@gnu.org> > CC: eliz@gnu.org, monnier@iro.umontreal.ca, jearl@notengoamigos.org, > emacs-devel@gnu.org > Reply-to: rms@gnu.org > Date: Thu, 03 Dec 2009 07:22:19 -0500 > > I will ping the sysadmins about updating bzr on fencepost. Thank you. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-03 12:22 ` Richard Stallman 2009-12-03 15:32 ` Eli Zaretskii @ 2009-12-03 17:44 ` Karl Fogel 1 sibling, 0 replies; 77+ messages in thread From: Karl Fogel @ 2009-12-03 17:44 UTC (permalink / raw) To: rms; +Cc: eliz, emacs-devel, monnier, jearl Richard Stallman <rms@gnu.org> writes: > I will ping the sysadmins about updating bzr on fencepost. Thank you! Please have them upgrade to bzr 2.0.2, which is in Debian backports now. The Bazaar developers say it is noticeably better to run 2.0.2 than 1.x versions (which is what we have now). Search for "bzr_2.0.2" in here: http://www.backports.org/debian/pool/main/b/bzr/ Assuming they upgrade on both fencepost and savannah, this might solve our loggerhead (repository/branch browsing) problems too (sr #107142). I asked in #bzr and the loggerhead 1.17 should be compatible with Bazaar 2.0.2. -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 15:59 ` Karl Fogel 2009-12-02 17:44 ` Eli Zaretskii @ 2009-12-02 18:40 ` Óscar Fuentes 2009-12-02 21:21 ` Martin Albisetti 2009-12-04 0:31 ` Stephen J. Turnbull 1 sibling, 2 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-12-02 18:40 UTC (permalink / raw) To: emacs-devel Karl Fogel <kfogel@red-bean.com> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Yes, it's slow. "bzr annotate" in a lightweight checkout takes almost >>> 3 minutes here. What's worse, it seems to send the entire annotated >>> source downstream in one big chunk, whereas CVS seemed to send it in >> >> Remember that the network protocol used is sftp, so the remote >> repository is "dumb" and cannot perform any operation such as >> "annotate". So when you do an "annotate", nothing is sent upstream >> other than commands to fetch files that contain the relevant parts of >> history, and then the annotate operation is performed locally. > > I'm hoping we can change that soon, with bzr+ssh access. See > https://savannah.gnu.org/support/?107077 for details. Certainly, we don't want to to use the savannah server for `annotate' nor for other VC operations that can be performed locally. If some people start using lightweight checkouts, a few simultaneous `log' and `annotate' can bring the server's CPU to its knees. I'll vote for disabling those operations on the server, if possible. BTW, how well does concurrency the smart server? It blocks writes when a read operation is performed? [snip] -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 18:40 ` Óscar Fuentes @ 2009-12-02 21:21 ` Martin Albisetti 2009-12-04 0:31 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: Martin Albisetti @ 2009-12-02 21:21 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Wed, Dec 2, 2009 at 3:40 PM, Óscar Fuentes <ofv@wanadoo.es> wrote: > BTW, how well does concurrency the smart server? It blocks writes when a > read operation is performed? Pretty well. Launchpad uses the smart server extensively. Reads do not generally block writes, AFAICT. -- Martin ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 18:40 ` Óscar Fuentes 2009-12-02 21:21 ` Martin Albisetti @ 2009-12-04 0:31 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-12-04 0:31 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > BTW, how well does concurrency the smart server? It blocks writes when a > read operation is performed? Well, and no. There have been bugs in locking, of course, but the basic design has always been sound and the implementation has only rarely been excessively fussy about locking. In fact as far as I know most of the write operation (ie, repacking) is done without locking the repo; the history data is written to temp files, and locks are held just long enough to update the metadata atomically. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 14:42 ` Stefan Monnier 2009-12-02 15:59 ` Karl Fogel @ 2009-12-02 18:29 ` Óscar Fuentes 1 sibling, 0 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-12-02 18:29 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: [snip] >> received. (With a local branch, "bzr annotate" takes about 30 >> seconds, not exactly the speed of light, either.) > > Yes, it's a fairly slow operation, sadly. I encourage you to complain > to the Bazaar developers about it, Operations that traverse history are intrinsically slow in Bazaar. Some improvements can be made (microoptimizations, mostly) but they will never be as fast as CVS (and I'm talking about bzr with local history vs remote CVS server). OTOH, `log' and `annotate' with local history are CPU-bound. A `log' in almost any Emacs source file takes 6.2 seconds on a 2.4 GHz workstation-class CPU and 22 seconds on a netbook. Worse, the `log' does not produce any output until the end, and it requires the same time even when you use the -l command line option for limiting the output at the first N revisions. After I complained about this on Bazaar's ml, a developer is attempting to change `log' for outputting stuff as soon as possible and stop when the required number of revisions is met, but so far he is disappointed seeing that his change makes the total time required by a plain `bzr log' even larger. Of course this is a wrong POV, but they give a lot of importance to raw performance numbers. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 20:21 ` Eli Zaretskii 2009-12-02 1:28 ` Stefan Monnier @ 2009-12-02 2:07 ` Stephen J. Turnbull 2009-12-03 1:22 ` Richard Stallman 1 sibling, 1 reply; 77+ messages in thread From: Stephen J. Turnbull @ 2009-12-02 2:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kfogel, ofv, Jason Earl, emacs-devel Eli Zaretskii writes: > I hope my opinions on this are clear enough. I don't think I will > use the CVS-like setup, but I see no reason not to help those who > will. So you're going to support those users? Great! ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-02 2:07 ` Stephen J. Turnbull @ 2009-12-03 1:22 ` Richard Stallman 2009-12-03 9:08 ` David Kastrup 2009-12-04 0:21 ` Stephen J. Turnbull 0 siblings, 2 replies; 77+ messages in thread From: Richard Stallman @ 2009-12-03 1:22 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: kfogel, ofv, eliz, jearl, emacs-devel To write information on a certain way of using bzr does not imply that you have an obligation to answer users' questions about it. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-03 1:22 ` Richard Stallman @ 2009-12-03 9:08 ` David Kastrup 2009-12-04 0:21 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: David Kastrup @ 2009-12-03 9:08 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > To write information on a certain way of using bzr does not imply that > you have an obligation to answer users' questions about it. It has been my experience that it wastes far too much time and emotional effort to omit answers for reoccuring questions one actually considers somebody else's business. Nobody thanks you for educating him, in particularly not when you do that in the almost compulsory terse tone when asked the same unnecessary question for the hundredth time. -- David Kastrup ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-03 1:22 ` Richard Stallman 2009-12-03 9:08 ` David Kastrup @ 2009-12-04 0:21 ` Stephen J. Turnbull 1 sibling, 0 replies; 77+ messages in thread From: Stephen J. Turnbull @ 2009-12-04 0:21 UTC (permalink / raw) To: rms; +Cc: kfogel, ofv, eliz, jearl, emacs-devel Richard Stallman writes: > To write information on a certain way of using bzr does not imply that > you have an obligation to answer users' questions about it. Of course it does not. In fact, I no longer feel any (self-imposed) obligation to answer any questions about Bazaar. :-) That won't stop me if I happen to have time or interest, of course, but I've to this point "made" about a full work day's worth of time to do productive work on the thread (ie, editing the wiki and/or researching Bazaar behavior, not including writing email) sooner than I would if just for my own interest. No more -- thanks for saving me the time and effort! :-) ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 19:56 ` Jason Earl 2009-12-01 20:21 ` Eli Zaretskii @ 2009-12-02 7:33 ` Richard Stallman 1 sibling, 0 replies; 77+ messages in thread From: Richard Stallman @ 2009-12-02 7:33 UTC (permalink / raw) To: Jason Earl; +Cc: kfogel, ofv, eliz, emacs-devel > The setup and workflow described by this page is advertised (by its > parent "Bzr For Emacs Devs") as ``CVS-like''. But this isn't really > accurate, is it? The command shown to checkout the trunk is this: If several methods are simple and fairly similar to CVS, the Quick Start recommendation does not have to be the one that is absolutely simplest or absolutely most similar to CVS. If another that is also rather simple and rather like CVS is better in some other way, it is ok to use. So there is no a priori reason to change it to suggest lightweight checkins. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 19:03 ` Eli Zaretskii 2009-12-01 19:56 ` Jason Earl @ 2009-12-01 21:44 ` Óscar Fuentes 2009-12-01 22:06 ` Karl Fogel 2009-12-01 21:53 ` Stefan Monnier 2 siblings, 1 reply; 77+ messages in thread From: Óscar Fuentes @ 2009-12-01 21:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > The setup and workflow described by this page is advertised (by its > parent "Bzr For Emacs Devs") as ``CVS-like''. I'll better describe that workflow as "centralized", versus the "distributed" one described on BzrForEmacsDevs. > But this isn't really accurate, is it? The command shown to checkout > the trunk is this: > > bzr checkout URL_TO_UPSTREAM_TRUNK trunk > > However, IIUC, the slightly modified checkout command > > bzr checkout --lightweight URL_TO_UPSTREAM_TRUNK trunk > > is a closer equivalent of the CVS checkout, because it only checks out > the working tree without creating a full local copy of history. Please note that the guide itself does not pretend to simulate CVS, but just exploit the concepts familiar to any CVS user for easing his transition to Bazaar as the Emacs' VCS. > The history is only needed if one wants to commit locally. People who > don't plan on using local commits don't need to pay the extra price of > larger disk storage and probably also some additional time it takes to > do a heavyweight checkout. The guide's goal is not the be exhaustive, but be simple. Mentioning the --lightweight option would increase complexity explaining one variant that hardly any Emacs hacker would appreciate once he starts using that setup. I can expand on this if you are interested. > OTOH, if we think that a heavyweight checkout is the recommended way, > then we should at least mention its main benefit -- the local commit. > Currently, the page only hints on that, but stops short of showing the > commands to use this potential: On a previous version of the wiki page there was a brief description of --local option for `commit'. It was removed following the suggestions of one the authors of the other guide. [snip] > Personally, I would do both: tell about --lightweight as the > equivalent of CVS, and also tell about the local commits available > with the heavyweight checkouts. But that's me. Thanks for your comments. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 21:44 ` Óscar Fuentes @ 2009-12-01 22:06 ` Karl Fogel 0 siblings, 0 replies; 77+ messages in thread From: Karl Fogel @ 2009-12-01 22:06 UTC (permalink / raw) To: Óscar Fuentes; +Cc: Eli Zaretskii, emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Eli Zaretskii <eliz@gnu.org> writes: >> The setup and workflow described by this page is advertised (by its >> parent "Bzr For Emacs Devs") as ``CVS-like''. > > I'll better describe that workflow as "centralized", versus the > "distributed" one described on BzrForEmacsDevs. Agreed, FWIW (I think I introduced "CVS-like" there, but I'm not wedded to it, and "centralized" may be the better term). -Karl ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 19:03 ` Eli Zaretskii 2009-12-01 19:56 ` Jason Earl 2009-12-01 21:44 ` Óscar Fuentes @ 2009-12-01 21:53 ` Stefan Monnier 2 siblings, 0 replies; 77+ messages in thread From: Stefan Monnier @ 2009-12-01 21:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, ofv, emacs-devel > is a closer equivalent of the CVS checkout, because it only checks out > the working tree without creating a full local copy of history. The > history is only needed if one wants to commit locally. People who > don't plan on using local commits don't need to pay the extra price of > larger disk storage and probably also some additional time it takes to > do a heavyweight checkout. > OTOH, if we think that a heavyweight checkout is the recommended way, > then we should at least mention its main benefit -- the local commit. The local commit (at least via --local) is not for the faint of heart (at least it got me confused several times, because when you later dp an "update", it seems to label the conflicts in ways that make me believe that my changes are actually the ones fetched from upstream and vice-versa). So, no, it's not the main feature. The main feature is that "bzr diff", "bzr log", and friends will work without requiring access to the remote repository. > Currently, the page only hints on that, but stops short of showing the > commands to use this potential: > You have in your disk a copy of the VC history of the trunk branch > since the last bzr update. Hence, Bazaar does not need to contact a > server upstream for displaying logs, reverting edited files, > annotating, etc. This is useful for working off-line. > Bazaar makes possible to commit changes off-line to your local history > and send them upstream in one batch. > Personally, I would do both: tell about --lightweight as the > equivalent of CVS, and also tell about the local commits available > with the heavyweight checkouts. But that's me. I could agree to adding some comment about the use of "unbind" to turn a heavyweight checkout into a plain branch. But maybe it's even better to not present "heavyweight checkout" and instead only present the "standalone branch" instead: checkout via: bzr branch <foo> update via: bzr pull commit via: bzr commit; bzr push Stefan ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-12-01 6:21 ` Óscar Fuentes 2009-12-01 6:52 ` Karl Fogel @ 2009-12-02 7:32 ` Richard Stallman 1 sibling, 0 replies; 77+ messages in thread From: Richard Stallman @ 2009-12-02 7:32 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel I have the impression that some people thinks that having developers not using a distributed workflow since day one would signal a failed transition, or a failure of Bazaar itself adapting to the project. Quite the contrary: the fact that Bazaar supports multiple compatible workflows allowing each user to choose whatever suits him better is, possibly, the best selling point for Bazaar. I agree. If the decentralized method helps you, by all means use it. I am even prepared to believe that using it is a worthwhile investment for most or all people making medium or large changes. I only object to pushing it on people making small changes, the sort that with CVS would be installed all at once. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Basic Bazaar guide for Emacs hackers. 2009-11-27 23:19 Basic Bazaar guide for Emacs hackers Óscar Fuentes ` (3 preceding siblings ...) 2009-11-30 2:05 ` Karl Fogel @ 2009-11-30 6:44 ` Glenn Morris 4 siblings, 0 replies; 77+ messages in thread From: Glenn Morris @ 2009-11-30 6:44 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes wrote: > http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs Thanks for writing such a document. A basic "here is what you need to do in order to keep on doing what you have been doing" is all I have wanted to see. Please don't delete it. ^ permalink raw reply [flat|nested] 77+ messages in thread
* Basic Bazaar guide for Emacs hackers. @ 2009-11-27 21:34 Óscar Fuentes 0 siblings, 0 replies; 77+ messages in thread From: Óscar Fuentes @ 2009-11-27 21:34 UTC (permalink / raw) To: help-gnu-emacs http://www.emacswiki.org/cgi-bin/emacs/BzrQuickStartForEmacsDevs I know some of you are pushing hard for introducing complete and correct dVCS practices among the Emacs developers. That is laudable but IMHO unrealistic to expect since day one. So it is intended as a minimum knowledge guide for not being left out. It is an appetizer too. If you think that it is the wrong way to (not) enter dVCS, I'll delete it or put a big warning sign at the beginning. Feel free to correct typos, grammar, etc. But please keep it minimalistic. -- Óscar ^ permalink raw reply [flat|nested] 77+ messages in thread
end of thread, other threads:[~2009-12-04 0:31 UTC | newest] Thread overview: 77+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-11-27 23:19 Basic Bazaar guide for Emacs hackers Óscar Fuentes 2009-11-28 1:23 ` Stephen J. Turnbull 2009-11-28 1:48 ` Óscar Fuentes 2009-11-28 2:05 ` Stefan Monnier 2009-11-28 7:10 ` Stephen J. Turnbull 2009-11-28 3:10 ` Richard Stallman 2009-11-28 3:48 ` Óscar Fuentes 2009-11-28 7:29 ` Stephen J. Turnbull 2009-11-29 1:16 ` Richard Stallman 2009-11-28 7:27 ` Stephen J. Turnbull 2009-11-28 10:05 ` Eli Zaretskii 2009-11-29 1:16 ` Richard Stallman 2009-11-29 4:38 ` Óscar Fuentes 2009-11-29 5:27 ` Stephen J. Turnbull 2009-11-29 5:52 ` Óscar Fuentes 2009-11-29 7:00 ` Stephen J. Turnbull 2009-11-29 16:29 ` Óscar Fuentes 2009-11-30 1:36 ` Stephen J. Turnbull 2009-11-30 15:52 ` Richard Stallman 2009-11-30 2:05 ` Karl Fogel 2009-11-30 2:17 ` Lennart Borgman 2009-11-30 2:46 ` Stephen J. Turnbull 2009-11-30 3:26 ` Óscar Fuentes 2009-11-30 3:51 ` Karl Fogel 2009-11-30 5:01 ` Stephen J. Turnbull 2009-11-30 5:20 ` Óscar Fuentes 2009-11-30 6:03 ` Karl Fogel 2009-11-30 6:41 ` Óscar Fuentes 2009-11-30 7:21 ` Stephen J. Turnbull 2009-11-30 19:27 ` Eli Zaretskii 2009-11-30 19:37 ` Karl Fogel 2009-11-30 20:36 ` Eli Zaretskii 2009-11-30 21:06 ` Karl Fogel 2009-12-01 1:53 ` Stephen J. Turnbull 2009-12-01 4:09 ` Richard Stallman 2009-11-30 6:41 ` Stephen J. Turnbull 2009-11-30 7:02 ` Óscar Fuentes 2009-11-30 9:17 ` Stephen J. Turnbull 2009-11-30 14:35 ` Karl Fogel 2009-11-30 15:31 ` Óscar Fuentes 2009-11-30 17:40 ` Stephen J. Turnbull 2009-11-30 18:02 ` Óscar Fuentes 2009-12-01 1:21 ` Stephen J. Turnbull 2009-11-30 19:21 ` Karl Fogel 2009-12-01 4:10 ` Richard Stallman 2009-12-01 6:21 ` Óscar Fuentes 2009-12-01 6:52 ` Karl Fogel 2009-12-01 8:34 ` Jason Rumney 2009-12-01 15:26 ` Karl Fogel 2009-12-01 19:03 ` Eli Zaretskii 2009-12-01 19:56 ` Jason Earl 2009-12-01 20:21 ` Eli Zaretskii 2009-12-02 1:28 ` Stefan Monnier 2009-12-02 7:20 ` Eli Zaretskii 2009-12-02 14:42 ` Stefan Monnier 2009-12-02 15:59 ` Karl Fogel 2009-12-02 17:44 ` Eli Zaretskii 2009-12-02 18:16 ` Karl Fogel 2009-12-02 18:20 ` Eli Zaretskii 2009-12-03 12:22 ` Richard Stallman 2009-12-03 15:32 ` Eli Zaretskii 2009-12-03 17:44 ` Karl Fogel 2009-12-02 18:40 ` Óscar Fuentes 2009-12-02 21:21 ` Martin Albisetti 2009-12-04 0:31 ` Stephen J. Turnbull 2009-12-02 18:29 ` Óscar Fuentes 2009-12-02 2:07 ` Stephen J. Turnbull 2009-12-03 1:22 ` Richard Stallman 2009-12-03 9:08 ` David Kastrup 2009-12-04 0:21 ` Stephen J. Turnbull 2009-12-02 7:33 ` Richard Stallman 2009-12-01 21:44 ` Óscar Fuentes 2009-12-01 22:06 ` Karl Fogel 2009-12-01 21:53 ` Stefan Monnier 2009-12-02 7:32 ` Richard Stallman 2009-11-30 6:44 ` Glenn Morris -- strict thread matches above, loose matches on Subject: below -- 2009-11-27 21:34 Óscar Fuentes
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.