* Strange message from "bzr pull" @ 2009-12-29 7:43 Eli Zaretskii 2009-12-29 10:18 ` Juanma Barranquero 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 7:43 UTC (permalink / raw) To: emacs-devel I've just created a local Bazaar repository for Emacs and initialized and bootstrapped the quickfixes branch, as described in BzrForEmacsDevs emacswiki page. This is on a GNU/Linux machine with bzr 2.0.0. After bootstrapping, I chdir'ed back to trunk and typed "bzr pull". Note that there were no changes whatsoever in this repository, so all I expected to see was the usual "Now on revision NNNN." message. Instead, I saw this: M lisp/ChangeLog M lisp/vc-bzr.el All changes applied successfully. Now on revision 99211. In CVS, the "M" marker meant that I have local uncommitted changes. But I don't have such changes here, at least not consciously. So what does this message mean, and how do I dig into the reasons for it (if there are any)? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 7:43 Strange message from "bzr pull" Eli Zaretskii @ 2009-12-29 10:18 ` Juanma Barranquero 2009-12-29 10:30 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Juanma Barranquero @ 2009-12-29 10:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Tue, Dec 29, 2009 at 08:43, Eli Zaretskii <eliz@gnu.org> wrote: > After bootstrapping, I chdir'ed back to trunk and typed "bzr pull". > Note that there were no changes whatsoever in this repository, so all > I expected to see was the usual "Now on revision NNNN." message. > Instead, I saw this: > > M lisp/ChangeLog > M lisp/vc-bzr.el > All changes applied successfully. > Now on revision 99211. > > In CVS, the "M" marker meant that I have local uncommitted changes. > But I don't have such changes here, at least not consciously. So what > does this message mean, and how do I dig into the reasons for it (if > there are any)? It just means that pull brought changes for these files. Try doing "bzr status" on trunk/; it should show no local modifications. Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 10:18 ` Juanma Barranquero @ 2009-12-29 10:30 ` Eli Zaretskii 2009-12-29 12:40 ` Juanma Barranquero 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 10:30 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 29 Dec 2009 11:18:40 +0100 > Cc: emacs-devel@gnu.org > > > M lisp/ChangeLog > > M lisp/vc-bzr.el > > All changes applied successfully. > > Now on revision 99211. > > > > In CVS, the "M" marker meant that I have local uncommitted changes. > > But I don't have such changes here, at least not consciously. So what > > does this message mean, and how do I dig into the reasons for it (if > > there are any)? > > It just means that pull brought changes for these files. So it's like "P" in CVS. What surprised me was that I never saw such messages from "bzr pull" when the bzr repository was just the result of CVS conversion by Andreas, as opposed to a writable repository it is now. Why didn't I see such messages back then? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 10:30 ` Eli Zaretskii @ 2009-12-29 12:40 ` Juanma Barranquero 2009-12-29 16:24 ` Eli Zaretskii 2009-12-29 18:02 ` Eli Zaretskii 0 siblings, 2 replies; 37+ messages in thread From: Juanma Barranquero @ 2009-12-29 12:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Tue, Dec 29, 2009 at 11:30, Eli Zaretskii <eliz@gnu.org> wrote: > What surprised me was that I never saw such messages from "bzr pull" > when the bzr repository was just the result of CVS conversion by > Andreas, as opposed to a writable repository it is now. Why didn't I > see such messages back then? Have you installed the repo anew after the switchover? AFAIK, the M means that the working copy file has been updated. The original instructions had the trunk created with bzr branch --no-tree sftp://... so trunk/ had no working copy. Karl changed that perhaps two weeks ago. I know because a while ago I recreated the repo and had a hard time understanding the difference in both trunks, until I thought of looking at the history of the BzrForEmacsDevs page :-) Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 12:40 ` Juanma Barranquero @ 2009-12-29 16:24 ` Eli Zaretskii 2009-12-29 17:00 ` Karl Fogel 2009-12-29 18:02 ` Eli Zaretskii 1 sibling, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 16:24 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 29 Dec 2009 13:40:08 +0100 > Cc: emacs-devel@gnu.org > > On Tue, Dec 29, 2009 at 11:30, Eli Zaretskii <eliz@gnu.org> wrote: > > > What surprised me was that I never saw such messages from "bzr pull" > > when the bzr repository was just the result of CVS conversion by > > Andreas, as opposed to a writable repository it is now. Why didn't I > > see such messages back then? > > Have you installed the repo anew after the switchover? Yes. (The previous one was on another box, anyway.) > AFAIK, the M means that the working copy file has been updated. The > original instructions had the trunk created with > > bzr branch --no-tree sftp://... > > so trunk/ had no working copy. Karl changed that perhaps two weeks ago. You are right, thanks for unlocking the mystery. But why were these instructions changed? I thought having the trunk treeless had some clear advantages, the physical impossibility of editing there being one of them. Karl? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 16:24 ` Eli Zaretskii @ 2009-12-29 17:00 ` Karl Fogel 2009-12-29 18:10 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Karl Fogel @ 2009-12-29 17:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Have you installed the repo anew after the switchover? > >Yes. (The previous one was on another box, anyway.) > >> AFAIK, the M means that the working copy file has been updated. The >> original instructions had the trunk created with >> >> bzr branch --no-tree sftp://... >> >> so trunk/ had no working copy. Karl changed that perhaps two weeks ago. > >You are right, thanks for unlocking the mystery. > >But why were these instructions changed? I thought having the trunk >treeless had some clear advantages, the physical impossibility of >editing there being one of them. > >Karl? I changed it because in actually testing the instructions, I discovered that the old instructions did not work :-). Here is the revision message from the wiki: 2009-12-07 19:47 UTC Revision 56 (KarlFogel) ==================================================================== Remove the --no-tree recommendation for the local trunk mirror. In order for merging into trunk (from local development branches) to work, there has to be a working tree in the merge destination. Otherwise you will get an error like, e.g., 'bzr: ERROR: No WorkingTree exists for "file:///home/kfogel/src/emacs/trunk/.bzr/checkout/".' -Karl ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 17:00 ` Karl Fogel @ 2009-12-29 18:10 ` Eli Zaretskii 2009-12-29 18:13 ` Juanma Barranquero 2009-12-29 18:44 ` Karl Fogel 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 18:10 UTC (permalink / raw) To: Karl Fogel; +Cc: lekktu, emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org > Date: Tue, 29 Dec 2009 12:00:11 -0500 > > I changed it because in actually testing the instructions, I discovered > that the old instructions did not work :-). Here is the revision > message from the wiki: > > 2009-12-07 19:47 UTC Revision 56 (KarlFogel) > ==================================================================== > Remove the --no-tree recommendation for the local trunk mirror. In > order for merging into trunk (from local development branches) to > work, there has to be a working tree in the merge > destination. Otherwise you will get an error like, e.g., 'bzr: ERROR: > No WorkingTree exists for > "file:///home/kfogel/src/emacs/trunk/.bzr/checkout/".' So does that mean there's a bug in bzr? If not, then what are tree-less repositories good for? It sounds a pity to have a tree that is never used in any way. It just wastes disk space. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 18:10 ` Eli Zaretskii @ 2009-12-29 18:13 ` Juanma Barranquero 2009-12-29 18:34 ` Eli Zaretskii 2009-12-29 18:44 ` Karl Fogel 1 sibling, 1 reply; 37+ messages in thread From: Juanma Barranquero @ 2009-12-29 18:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, emacs-devel On Tue, Dec 29, 2009 at 19:10, Eli Zaretskii <eliz@gnu.org> wrote: > It sounds a pity to have a tree that is never used in any way. It > just wastes disk space. But on the proposed workflow, the tree *is* used. To merge the changes from the task branches, and to commit upstream. Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 18:13 ` Juanma Barranquero @ 2009-12-29 18:34 ` Eli Zaretskii 2009-12-29 19:28 ` Óscar Fuentes 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 18:34 UTC (permalink / raw) To: Juanma Barranquero; +Cc: kfogel, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 29 Dec 2009 19:13:33 +0100 > Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org > > On Tue, Dec 29, 2009 at 19:10, Eli Zaretskii <eliz@gnu.org> wrote: > > > It sounds a pity to have a tree that is never used in any way. It > > just wastes disk space. > > But on the proposed workflow, the tree *is* used. To merge the changes > from the task branches, and to commit upstream. I don't know enough about bzr internals, but I was under the impression that the tree-less repository has all the information needed for that, albeit not in the form of the Emacs source files. Otherwise, how could you "bzr branch" from the trunk acting as local repository? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 18:34 ` Eli Zaretskii @ 2009-12-29 19:28 ` Óscar Fuentes 2009-12-29 19:51 ` Karl Fogel 2009-12-29 20:16 ` Eli Zaretskii 0 siblings, 2 replies; 37+ messages in thread From: Óscar Fuentes @ 2009-12-29 19:28 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > It sounds a pity to have a tree that is never used in any way. It >> > just wastes disk space. >> >> But on the proposed workflow, the tree *is* used. To merge the changes >> from the task branches, and to commit upstream. > > I don't know enough about bzr internals, but I was under the > impression that the tree-less repository has all the information > needed for that, albeit not in the form of the Emacs source files. Merging may cause conflicts, which require editing files. This is why you need the source files on that branch. [snip] On the topic of spoon-feeding the developers with bzr recipes, I think it is quite pertinent if the recipe is simple enough. BzrForEmacsDevs is not simple enough for people who have CVS incorporated into their DNA. IMHO it lacks some clear explanation of the new concepts (revisions, branches, merges, histories, divergence, etc) so they can figure out what's going on, see most of the new possibilities and ask to the "gurus" for advice using a discernible language when they cannot decide among several options. Using a new workflow without a sufficient understanding of the basic concepts may cause mistakes and frustration. Maybe a pointer to some generic introduction to DVCS plus a description of how Bazaar implements it would be okay (I don't know any such decent introduction specific for Bazaar, though.) -- Óscar ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 19:28 ` Óscar Fuentes @ 2009-12-29 19:51 ` Karl Fogel 2009-12-29 20:04 ` Óscar Fuentes 2009-12-29 20:16 ` Eli Zaretskii 1 sibling, 1 reply; 37+ messages in thread From: Karl Fogel @ 2009-12-29 19:51 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: >BzrForEmacsDevs is not simple enough for people who have CVS >incorporated into their DNA. IMHO it lacks some clear explanation of the >new concepts (revisions, branches, merges, histories, divergence, etc) >so they can figure out what's going on, see most of the new >possibilities and ask to the "gurus" for advice using a discernible >language when they cannot decide among several options. Using a new >workflow without a sufficient understanding of the basic concepts may >cause mistakes and frustration. Maybe a pointer to some generic >introduction to DVCS plus a description of how Bazaar implements it >would be okay (I don't know any such decent introduction specific for >Bazaar, though.) Several places in the document (including the The Other Resources section) already point to http://wiki.bazaar.canonical.com/BzrForCVSUsers, which has the material you describe. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 19:51 ` Karl Fogel @ 2009-12-29 20:04 ` Óscar Fuentes 2009-12-29 20:15 ` Karl Fogel ` (2 more replies) 0 siblings, 3 replies; 37+ messages in thread From: Óscar Fuentes @ 2009-12-29 20:04 UTC (permalink / raw) To: emacs-devel Karl Fogel <kfogel@red-bean.com> writes: >>BzrForEmacsDevs is not simple enough for people who have CVS >>incorporated into their DNA. IMHO it lacks some clear explanation of >>the new concepts (revisions, branches, merges, histories, divergence, >>etc) > > Several places in the document (including the The Other Resources > section) already point to > http://wiki.bazaar.canonical.com/BzrForCVSUsers, which has the material > you describe. That document is too shallow, barely qualifies as an introduction. It doesn't hint at what a revision, for instance. Nobody that reads that document knows that the key information that makes DVCS possible is what you see with bzr log --show-ids -- Óscar ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 20:04 ` Óscar Fuentes @ 2009-12-29 20:15 ` Karl Fogel 2009-12-29 20:29 ` Eli Zaretskii 2009-12-31 9:39 ` Stephen J. Turnbull 2 siblings, 0 replies; 37+ messages in thread From: Karl Fogel @ 2009-12-29 20:15 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: >That document is too shallow, barely qualifies as an introduction. It >doesn't hint at what a revision, for instance. Nobody that reads that >document knows that the key information that makes DVCS possible is what >you see with > >bzr log --show-ids It sounds like you know what needs to be done. Please do it! ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 20:04 ` Óscar Fuentes 2009-12-29 20:15 ` Karl Fogel @ 2009-12-29 20:29 ` Eli Zaretskii 2009-12-29 23:32 ` Óscar Fuentes 2009-12-31 9:39 ` Stephen J. Turnbull 2 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 20:29 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Tue, 29 Dec 2009 21:04:42 +0100 > > > Several places in the document (including the The Other Resources > > section) already point to > > http://wiki.bazaar.canonical.com/BzrForCVSUsers, which has the material > > you describe. > > That document is too shallow, barely qualifies as an introduction. Agreed. > Nobody that reads that document knows that the key information that > makes DVCS possible is what you see with > > bzr log --show-ids And why is that information important? More to the point, where _is_ it described? What I see is this: revno: 99212 [merge] revision-id: nickrob@snap.net.nz-20091229072200-2capgobhol086ef3 parent: dann@ics.uci.edu-20091229064608-lpeenthwsy3zp0vy parent: nickrob@snap.net.nz-20091229071534-bdspozxb6idtp7z0 committer: Nick Roberts <nickrob@snap.net.nz> branch nick: trunk timestamp: Tue 2009-12-29 20:22:00 +1300 message: This changeset reverts GDB Graphical Interface to use annotations. It incorporates features added (and never released) on the EMACS_23_1_RC branch. Namely reverse debugging and the display of STL collections as watch expressions. The long term aim is to move to GDB/MI, so these changes will be re-instated at some time in the future. At the moment, however, there are issues with gdb-mi.el that have not yet been solved, e.g, bug#5145. ------------------------------------------------------------ revno: 99211 revision-id: dann@ics.uci.edu-20091229064608-lpeenthwsy3zp0vy parent: lekktu@gmail.com-20091229015740-2d6hdl0fcs6e88b0 committer: Dan Nicolaescu <dann@ics.uci.edu> branch nick: trunk timestamp: Mon 2009-12-28 22:46:08 -0800 message: Make vc-dir work on subdirectories of the bzr root. * vc-bzr.el (vc-bzr-after-dir-status): Add new argument. Return file names relative to it. (vc-bzr-dir-status, vc-bzr-dir-status-files): Pass the bzr root relative directory to vc-bzr-after-dir-status. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 20:29 ` Eli Zaretskii @ 2009-12-29 23:32 ` Óscar Fuentes 2009-12-30 4:16 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Óscar Fuentes @ 2009-12-29 23:32 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: [snip] >> Nobody that reads that document knows that the key information that >> makes DVCS possible is what you see with >> >> bzr log --show-ids > > And why is that information important? Distributed version control is about exchanging revisions. You need a way to know what revisions you are missing from some other branch, and a way to know how the revisions are arranged. Those unique revision-ids are the solution. A branch is, essentially, a set of revisions arranged on a DAG. As far as Bazaar is concerned, the revision-id of a revision (and the revision-ids of its parents) is the interesting info. The revision number (revno) is only meaningful for a given branch or a mirror of it. Some tools, like git, do not try to use revision numbers and use the revision-id instead. This is the Right Thing but too much people think that those long unique ids are too cumbersome, so Bazaar and Mercurial have revision numbers too. Hence, when someone says "revision 98834 broke the build" he must take care of referring to the master trunk, and you shall look at that revision number on your local mirror of trunk, because other branches may have different numeration. But if you say "revision ofv@wanadoo.es-20091229071534-bdspozxb6idtp7z0 broke the build" you can see the changes it introduced on any branch with bzr diff -c revid:ofv@wanadoo.es-20091229071534-bdspozxb6idtp7z0 > More to the point, where _is_ it described? No idea. But the above description should suffice for our purposes. > What I see is this: > > revno: 99212 [merge] > revision-id: nickrob@snap.net.nz-20091229072200-2capgobhol086ef3 > parent: dann@ics.uci.edu-20091229064608-lpeenthwsy3zp0vy > parent: nickrob@snap.net.nz-20091229071534-bdspozxb6idtp7z0 This revision has two parents because it is a merge point. I'm sure you get the idea. [snip] -- Óscar ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 23:32 ` Óscar Fuentes @ 2009-12-30 4:16 ` Eli Zaretskii 2009-12-30 5:15 ` Óscar Fuentes 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-30 4:16 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Wed, 30 Dec 2009 00:32:56 +0100 > > Distributed version control is about exchanging revisions. You need a > way to know what revisions you are missing from some other branch, and a > way to know how the revisions are arranged. Those unique revision-ids > are the solution. But that makes sense only for branches bounded to remote repositories, right? For my own local branches, there's nothing interesting in this information. > > revno: 99212 [merge] > > revision-id: nickrob@snap.net.nz-20091229072200-2capgobhol086ef3 > > parent: dann@ics.uci.edu-20091229064608-lpeenthwsy3zp0vy > > parent: nickrob@snap.net.nz-20091229071534-bdspozxb6idtp7z0 > > This revision has two parents because it is a merge point. I'm sure you > get the idea. Yes, it looked so utterly trivial that I wondered why you were saying it was ``key information that made DVCS possible''. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 4:16 ` Eli Zaretskii @ 2009-12-30 5:15 ` Óscar Fuentes 0 siblings, 0 replies; 37+ messages in thread From: Óscar Fuentes @ 2009-12-30 5:15 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Distributed version control is about exchanging revisions. You need a >> way to know what revisions you are missing from some other branch, and a >> way to know how the revisions are arranged. Those unique revision-ids >> are the solution. > > But that makes sense only for branches bounded to remote repositories, > right? For my own local branches, there's nothing interesting in this > information. revision-ids are unnecessary for bound branches (after all, a bound branch is just a bit more than a local cache for the remote branch). A revision can reach a branch on a variety of ways, coming from different sources (a DVCS exchange network is fully point to point, it is not restricted to a star topology, although emacs is doing that currently) If you receive the same revision from two or more different sources, it is fundamental to notice that it is the same revision. BTW, there is not much difference among you having N local branches and N developers having a single branch each. Revision-ids are required for your own branches. -- Óscar ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 20:04 ` Óscar Fuentes 2009-12-29 20:15 ` Karl Fogel 2009-12-29 20:29 ` Eli Zaretskii @ 2009-12-31 9:39 ` Stephen J. Turnbull 2 siblings, 0 replies; 37+ messages in thread From: Stephen J. Turnbull @ 2009-12-31 9:39 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes writes: > Karl Fogel <kfogel@red-bean.com> writes: > > >>BzrForEmacsDevs is not simple enough for people who have CVS > >>incorporated into their DNA. IMHO it lacks some clear explanation of > >>the new concepts (revisions, branches, merges, histories, divergence, > >>etc) > > > > Several places in the document (including the The Other Resources > > section) already point to > > http://wiki.bazaar.canonical.com/BzrForCVSUsers, which has the material > > you describe. > > That document is too shallow, barely qualifies as an introduction. http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html may contain some useful information. It assumes substantial familiarity with git, so the very basic stuff is not given there. > It doesn't hint at what a revision, for instance. Nobody that reads > that document knows that the key information that makes DVCS > possible is what you see with > > bzr log --show-ids I agree that the concept that a revision has a universally unique ID needs to be mentioned, and that a branch knows which IDs it contains, and can therefore reproduce by updating a working tree. But the sentence I just wrote is horrible, nobody who doesn't already understand will learn anything from it :-), and I don't think a reference to "--show-ids" will help much. You need to explain what those IDs mean. Specifically, they represented directed arcs in a graph. I think that for Emacs developers it may be useful to think of a "commit" or "revision" by analogy to the Lisp cons. The "car" contains a pointer to the revision metadata and the actual content (files). The "cdr" is the parent revision. The obvious part of the generalization is that the "cdr" may be multiple-valued in the case of a merge commit, which has multiple parents. To continue the analogy, a branch is like a Lisp list, with the root commit being the final "cons" which has "cdr" of "nil" (ie, it has no parent). The less obvious part of the generalization is that in a DVCS the pointer(s) in the "cdr" (and in the "car") are *universal*. In the Emacs Lisp implementation those are machine addresses, and they are implementation details that are only exposed in the debugger. But in DVCS, that cannot be so: the communication protocol between different branches (even on the same host!) needs to use them. *Every* bzr branch either assigns the same universal meaning to the id, or it knows that that id is not part of the branch. It's true that the information about revision IDs and content IDs locally may not be of great interest at the moment. However, they will automatically be universally valid if you ever push from your branch, or somebody pulls from it. It is the universality that makes *distributed* VCS possible. N.B. With respect to git, this description is a pretty accurate description of the implementation. For Mercurial and Bazaar, the implementations are substantially different to support various features of each DVCS, but all of them do have a concept of the "history DAG", which is represented by links among "revision objects". ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 19:28 ` Óscar Fuentes 2009-12-29 19:51 ` Karl Fogel @ 2009-12-29 20:16 ` Eli Zaretskii 2009-12-29 23:14 ` Óscar Fuentes 1 sibling, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 20:16 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Tue, 29 Dec 2009 20:28:32 +0100 > > BzrForEmacsDevs is not simple enough for people who have CVS > incorporated into their DNA. IMHO it lacks some clear explanation of the > new concepts (revisions, branches, merges, histories, divergence, etc) > so they can figure out what's going on, see most of the new > possibilities and ask to the "gurus" for advice using a discernible > language when they cannot decide among several options. Using a new > workflow without a sufficient understanding of the basic concepts may > cause mistakes and frustration. But the basic concepts are common, more or less, to all modern VCSs. Revisions, branches, merges, histories -- all these exist even with CVS, and anyone who worked with a VCS in an organization probably knows what rebase and deliver mean already. What other concepts are new whose lack of understanding can prevent me from considering the pros and cons and cause me mistakes that will frustrate me? Mistakes can be done even with RCS, you know. > Maybe a pointer to some generic introduction to DVCS plus a > description of how Bazaar implements it would be okay (I don't know > any such decent introduction specific for Bazaar, though.) Whatever pointers you do have, please post them, even if they are not specific to Bazaar. Thanks. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 20:16 ` Eli Zaretskii @ 2009-12-29 23:14 ` Óscar Fuentes 2009-12-30 4:21 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Óscar Fuentes @ 2009-12-29 23:14 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > But the basic concepts are common, more or less, to all modern VCSs. > Revisions, branches, merges, histories -- all these exist even with > CVS, and anyone who worked with a VCS in an organization probably > knows what rebase and deliver mean already. Those concepts have added meaning in DVCSs. Assuming that a revision or a branch is the same for CVS and Bazaar will lead to confussion. Is like learning C++ assuming that is an extension of C or learning Spanish vocabulary thinking that your knowledge of French will make things straightforward. [snip] > Whatever pointers you do have, please post them, even if they are not > specific to Bazaar. Thanks. I was skimming the Internet for a while and found no docs that explained the concepts without focusing on specific approaches from other tools like git or mercurial. That could only mislead the Bazaar beginner. -- Óscar ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 23:14 ` Óscar Fuentes @ 2009-12-30 4:21 ` Eli Zaretskii 2009-12-30 4:28 ` Miles Bader 2009-12-30 5:26 ` Óscar Fuentes 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2009-12-30 4:21 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Wed, 30 Dec 2009 00:14:58 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > But the basic concepts are common, more or less, to all modern VCSs. > > Revisions, branches, merges, histories -- all these exist even with > > CVS, and anyone who worked with a VCS in an organization probably > > knows what rebase and deliver mean already. > > Those concepts have added meaning in DVCSs. I don't see anything about the added meaning here, for example: http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/core_concepts.html (which ironically enough says that the revision-ids are an internal detail that is not important to users). > I was skimming the Internet for a while and found no docs that explained > the concepts without focusing on specific approaches from other tools > like git or mercurial. That could only mislead the Bazaar beginner. Please mislead me. I read confusing prose for the living, so please do show those places, or at least suggest keywords for a Google search. Thanks. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 4:21 ` Eli Zaretskii @ 2009-12-30 4:28 ` Miles Bader 2009-12-30 5:26 ` Óscar Fuentes 1 sibling, 0 replies; 37+ messages in thread From: Miles Bader @ 2009-12-30 4:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/core_concepts.html > > (which ironically enough says that the revision-ids are an internal > detail that is not important to users). That sounds like wishful thinking... -Miles -- Bore, n. A person who talks when you wish him to listen. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 4:21 ` Eli Zaretskii 2009-12-30 4:28 ` Miles Bader @ 2009-12-30 5:26 ` Óscar Fuentes 1 sibling, 0 replies; 37+ messages in thread From: Óscar Fuentes @ 2009-12-30 5:26 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > Revisions, branches, merges, histories -- all these exist even with >> > CVS, and anyone who worked with a VCS in an organization probably >> > knows what rebase and deliver mean already. >> >> Those concepts have added meaning in DVCSs. > > I don't see anything about the added meaning here, for example: > > http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/core_concepts.html The bazaar docs are not that great explaining certain things. One clear example is their introduction for CVS users linked elsewhere and the document you referred is just a bit better: it defines certain things but do not explain why are they necessary. > (which ironically enough says that the revision-ids are an internal > detail that is not important to users). For the reason explained on a previous post, this is a bit unrealistic. >> I was skimming the Internet for a while and found no docs that explained >> the concepts without focusing on specific approaches from other tools >> like git or mercurial. That could only mislead the Bazaar beginner. > > Please mislead me. I read confusing prose for the living, so please > do show those places, or at least suggest keywords for a Google > search. Thanks. Okay, see this: http://eagain.net/articles/git-for-computer-scientists/ Bazaar uses a different approach for most of the details described there (and even for some fundamental things, as what really is tracked: content vs files) so keep in mind that wathever you learn there is, most likely, not applicable to bazaar in practice. -- Óscar ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 18:10 ` Eli Zaretskii 2009-12-29 18:13 ` Juanma Barranquero @ 2009-12-29 18:44 ` Karl Fogel 2009-12-29 19:01 ` Eli Zaretskii 1 sibling, 1 reply; 37+ messages in thread From: Karl Fogel @ 2009-12-29 18:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >So does that mean there's a bug in bzr? If not, then what are >tree-less repositories good for? The answer to that is "many thing", I think, just not things we happen to be doing here. On the server side, for example, all the branches are tree-less to save space, because there's no need for working trees there. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 18:44 ` Karl Fogel @ 2009-12-29 19:01 ` Eli Zaretskii 2009-12-29 19:09 ` Karl Fogel 2009-12-29 21:37 ` Stefan Monnier 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 19:01 UTC (permalink / raw) To: Karl Fogel; +Cc: lekktu, emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Date: Tue, 29 Dec 2009 13:44:21 -0500 > Cc: lekktu@gmail.com, emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > >So does that mean there's a bug in bzr? If not, then what are > >tree-less repositories good for? > > The answer to that is "many thing", I think, just not things we happen > to be doing here. OK. So, since we have this tree in trunk/, what are the reasons to keep it pristine, again? IOW, why not make quick and simple fixes in it directly, instead of in another branch? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 19:01 ` Eli Zaretskii @ 2009-12-29 19:09 ` Karl Fogel 2009-12-29 20:09 ` Eli Zaretskii 2009-12-29 21:37 ` Stefan Monnier 1 sibling, 1 reply; 37+ messages in thread From: Karl Fogel @ 2009-12-29 19:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Karl Fogel <kfogel@red-bean.com> >> Date: Tue, 29 Dec 2009 13:44:21 -0500 >> Cc: lekktu@gmail.com, emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >So does that mean there's a bug in bzr? If not, then what are >> >tree-less repositories good for? >> >> The answer to that is "many thing", I think, just not things we happen >> to be doing here. > >OK. So, since we have this tree in trunk/, what are the reasons to >keep it pristine, again? IOW, why not make quick and simple fixes in >it directly, instead of in another branch? I *think* that would work fine (though I'm not 100% positive, since I don't do it myself). The only reason I didn't document that is that if upstream gets new changes while the local edits are being made, then one would have to pull them in before committing -- because, as a bound branch, trunk is not supposed to diverge from what it's bound to. But they might conflict. Now your local trunk mirror is in a conflicted state. That's not a disaster -- it's easy enough to resolve things -- but the point of the trunk mirror is that it's always pristine, so that it can be used as a merge source for your local feature branches, etc. That's why in the other recipes, if you get conflicts, we just say "bzr revert" and pull, and then re-merge from the local branch to commit upstream. However, in this scenario, "bzr revert" would lose the *only* copy of the changes, unlike in all the other scenarios. So you really have to resolve the conflict right away, without reverting, and finish the commit. Thus trunk spends more time in a non-pristine state than is ideal, though it's not hard to get out of that if one needs to. None of this is terribly complicated, and I doubt any developer here would have a problem handling it, but I wasn't sure it was wise to introduce that little bit of extra complexity early on, especially as I didn't have personal experience with it and didn't know if the likelihood of unexpected gotchas. So if you test it and it works, and no one thinks of any reason why it could lead to bad history, then... go for it, I'd say. -Karl ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 19:09 ` Karl Fogel @ 2009-12-29 20:09 ` Eli Zaretskii 2009-12-30 7:02 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 20:09 UTC (permalink / raw) To: Karl Fogel; +Cc: lekktu, emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Cc: lekktu@gmail.com, emacs-devel@gnu.org > Date: Tue, 29 Dec 2009 14:09:43 -0500 > > >OK. So, since we have this tree in trunk/, what are the reasons to > >keep it pristine, again? IOW, why not make quick and simple fixes in > >it directly, instead of in another branch? > > I *think* that would work fine (though I'm not 100% positive, since I > don't do it myself). > > The only reason I didn't document that is that if upstream gets new > changes while the local edits are being made, then one would have to > pull them in before committing -- because, as a bound branch, trunk is > not supposed to diverge from what it's bound to. But they might > conflict. Now your local trunk mirror is in a conflicted state. Yes, understood. But I didn't intend to make any serious changes there, just the ``one-offs''. If only one or two files are modified, things will not become too ugly, I think, even if there are conflicts. > So if you test it and it works, and no one thinks of any reason why it > could lead to bad history, then... go for it, I'd say. Will do, thanks. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 20:09 ` Eli Zaretskii @ 2009-12-30 7:02 ` Eli Zaretskii 2009-12-30 12:19 ` Juanma Barranquero 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-30 7:02 UTC (permalink / raw) To: kfogel, emacs-devel > Date: Tue, 29 Dec 2009 22:09:02 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, emacs-devel@gnu.org > Reply-To: Eli Zaretskii <eliz@gnu.org> > > > From: Karl Fogel <kfogel@red-bean.com> > > Cc: lekktu@gmail.com, emacs-devel@gnu.org > > Date: Tue, 29 Dec 2009 14:09:43 -0500 > > > > >OK. So, since we have this tree in trunk/, what are the reasons to > > >keep it pristine, again? IOW, why not make quick and simple fixes in > > >it directly, instead of in another branch? > > > > I *think* that would work fine (though I'm not 100% positive, since I > > don't do it myself). > > > > The only reason I didn't document that is that if upstream gets new > > changes while the local edits are being made, then one would have to > > pull them in before committing -- because, as a bound branch, trunk is > > not supposed to diverge from what it's bound to. But they might > > conflict. Now your local trunk mirror is in a conflicted state. > > Yes, understood. But I didn't intend to make any serious changes > there, just the ``one-offs''. If only one or two files are modified, > things will not become too ugly, I think, even if there are conflicts. So what, if any, changes in the bzr configuration and in the workflow documented on the wiki would be necessary if the trunk/ tree is used for small one-off fixes? I understand that by binding this branch to the remote repository, we actually made it a checkout. Therefore, "bzr pull" that is documented on the wiki will only work if I have no local changes that are not committed to the central repository; otherwise, I need to use "bzr update", is that right? If so, perhaps it's better to say on the wiki that "bzr update" be always used in trunk/, because it will always work, no matter if the mirror diverged or not? Next, what is this public_branch directive in .bzr/branch/branch.conf. Its documentation in the manual is abysmally inadequate, but it sounds like it is only used in "bzr send"? If so, making changes in trunk/ does not need to change this (or any other) line in branch.conf, is that right? Any other consequences I missed? TIA ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 7:02 ` Eli Zaretskii @ 2009-12-30 12:19 ` Juanma Barranquero 2009-12-30 15:05 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Juanma Barranquero @ 2009-12-30 12:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kfogel, emacs-devel On Wed, Dec 30, 2009 at 08:02, Eli Zaretskii <eliz@gnu.org> wrote: > If so, perhaps it's better to say on the wiki that > "bzr update" be always used in trunk/, because it will always work, no > matter if the mirror diverged or not? If you look at the archives of the Bazaar list, there's a thread "bzr pull vs. bzr update" starting on Dec 16 where the issue is discussed (specifically with respect to Emacs and the BzrForEmacsDevs document). Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 12:19 ` Juanma Barranquero @ 2009-12-30 15:05 ` Eli Zaretskii 2009-12-30 15:19 ` Juanma Barranquero 2009-12-31 19:36 ` Karl Fogel 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2009-12-30 15:05 UTC (permalink / raw) To: Juanma Barranquero; +Cc: kfogel, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Wed, 30 Dec 2009 13:19:43 +0100 > Cc: kfogel@red-bean.com, emacs-devel@gnu.org > > On Wed, Dec 30, 2009 at 08:02, Eli Zaretskii <eliz@gnu.org> wrote: > > > If so, perhaps it's better to say on the wiki that > > "bzr update" be always used in trunk/, because it will always work, no > > matter if the mirror diverged or not? > > If you look at the archives of the Bazaar list, there's a thread "bzr > pull vs. bzr update" starting on Dec 16 where the issue is discussed > (specifically with respect to Emacs and the BzrForEmacsDevs document). Thanks for the pointer. After reading that, I think that the Emacswiki should recommend "bzr up", not "bzr pull". The main reason is that the Bazaar docs say one should use `update' in this configuration. Bazaar docs are far from ideal, but they are very clear on this issue. It doesn't make sense, IMO, to confuse newcomers to Bazaar by going against the user manual, especially if we want to save them from extra confusion. Besides, with the trunk not treeless anymore, the chances that one-off changes will be done there just became higher, and with them the risk of having "bzr pull" error out ==> more confusion, and IMO for no good reason. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 15:05 ` Eli Zaretskii @ 2009-12-30 15:19 ` Juanma Barranquero 2009-12-31 19:36 ` Karl Fogel 1 sibling, 0 replies; 37+ messages in thread From: Juanma Barranquero @ 2009-12-30 15:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Wed, Dec 30, 2009 at 16:05, Eli Zaretskii <eliz@gnu.org> wrote: > After reading that, I think that the Emacswiki should recommend "bzr up", > not "bzr pull". The main reason is that the Bazaar docs say one should > use `update' in this configuration. Bazaar docs are far from ideal, > but they are very clear on this issue. In that thread, Matthew D. Fuller clearly said: > If you want to update a checkout to catch up changes in the branch, > you want 'update'. That 'pull', with an appropriate parent location, > in a heavy checkout, also seems to do the same thing is sheer > coincidence and a terribly ugly break of the model. I think that says it all. Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-30 15:05 ` Eli Zaretskii 2009-12-30 15:19 ` Juanma Barranquero @ 2009-12-31 19:36 ` Karl Fogel 2009-12-31 20:49 ` Juanma Barranquero 1 sibling, 1 reply; 37+ messages in thread From: Karl Fogel @ 2009-12-31 19:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Juanma Barranquero <lekktu@gmail.com> >> Date: Wed, 30 Dec 2009 13:19:43 +0100 >> Cc: kfogel@red-bean.com, emacs-devel@gnu.org >> >> On Wed, Dec 30, 2009 at 08:02, Eli Zaretskii <eliz@gnu.org> wrote: >> >> > If so, perhaps it's better to say on the wiki that >> > "bzr update" be always used in trunk/, because it will always work, no >> > matter if the mirror diverged or not? >> >> If you look at the archives of the Bazaar list, there's a thread "bzr >> pull vs. bzr update" starting on Dec 16 where the issue is discussed >> (specifically with respect to Emacs and the BzrForEmacsDevs document). > >Thanks for the pointer. > >After reading that, I think that the Emacswiki should recommend "bzr up", >not "bzr pull". The main reason is that the Bazaar docs say one should >use `update' in this configuration. Bazaar docs are far from ideal, >but they are very clear on this issue. It doesn't make sense, IMO, to >confuse newcomers to Bazaar by going against the user manual, especially >if we want to save them from extra confusion. > >Besides, with the trunk not treeless anymore, the chances that one-off >changes will be done there just became higher, and with them the risk >of having "bzr pull" error out ==> more confusion, and IMO for no good >reason. (For reference, the thread we're talking about begins at [1]. Personally, I find it more easily navigable at Gmane [2].) The reason I went with 'pull' in the doc was because I thought we'd want an error if there were local commits. However, it's looking like some developers will be using trunk for small one-off changes, and as Juanma points out later in the thread [3], since trunk is a bound branch, a developer would have to use 'commit --local' to have any local commits there at all... which is so unlikely that if it happens, the person clearly did it on purpose and knows what they're doing. So between that and what you say above, it makes sense to me too to switch to recommending 'update' in the doc. I've done so. Thanks for synthesizing the arguments, Eli and Juanma. -K [1] https://lists.ubuntu.com/archives/bazaar/2009q4/065443.html [2] http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/64885/focus=64911 [3] http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/64885/focus=64911 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-31 19:36 ` Karl Fogel @ 2009-12-31 20:49 ` Juanma Barranquero 0 siblings, 0 replies; 37+ messages in thread From: Juanma Barranquero @ 2009-12-31 20:49 UTC (permalink / raw) To: Karl Fogel; +Cc: Eli Zaretskii, emacs-devel On Thu, Dec 31, 2009 at 20:36, Karl Fogel <kfogel@red-bean.com> wrote: > So between that and what you say above, it makes sense to me too to > switch to recommending 'update' in the doc. I've done so. Thanks for > synthesizing the arguments, Eli and Juanma. Eli's the master word synthesizer here (and I'm glad he convinced you). I have not been accused of discussing synthetically in my whole life. Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 19:01 ` Eli Zaretskii 2009-12-29 19:09 ` Karl Fogel @ 2009-12-29 21:37 ` Stefan Monnier 2009-12-31 9:43 ` Stephen J. Turnbull 1 sibling, 1 reply; 37+ messages in thread From: Stefan Monnier @ 2009-12-29 21:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, lekktu, emacs-devel > OK. So, since we have this tree in trunk/, what are the reasons to > keep it pristine, again? IOW, why not make quick and simple fixes in > it directly, instead of in another branch? No reason. You can work just with the trunk if you want. That is actually closer to what you'd do with CVS. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 21:37 ` Stefan Monnier @ 2009-12-31 9:43 ` Stephen J. Turnbull 0 siblings, 0 replies; 37+ messages in thread From: Stephen J. Turnbull @ 2009-12-31 9:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: Karl Fogel, lekktu, Eli Zaretskii, emacs-devel Stefan Monnier writes: > > OK. So, since we have this tree in trunk/, what are the reasons to > > keep it pristine, again? IOW, why not make quick and simple fixes in > > it directly, instead of in another branch? > > No reason. You can work just with the trunk if you want. That is > actually closer to what you'd do with CVS. I find it fascinating that everybody says "no reason not to", rather than "that's what I do." ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 12:40 ` Juanma Barranquero 2009-12-29 16:24 ` Eli Zaretskii @ 2009-12-29 18:02 ` Eli Zaretskii 2009-12-29 18:12 ` Juanma Barranquero 1 sibling, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2009-12-29 18:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 29 Dec 2009 13:40:08 +0100 > Cc: emacs-devel@gnu.org > > AFAIK, the M means that the working copy file has been updated. Btw, on the machine where trunk is without a tree, I didn't see M etc. in the quickfixes branch, either, although that one did have a tree. Is that expected? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Strange message from "bzr pull" 2009-12-29 18:02 ` Eli Zaretskii @ 2009-12-29 18:12 ` Juanma Barranquero 0 siblings, 0 replies; 37+ messages in thread From: Juanma Barranquero @ 2009-12-29 18:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Tue, Dec 29, 2009 at 19:02, Eli Zaretskii <eliz@gnu.org> wrote: > Btw, on the machine where trunk is without a tree, I didn't see M etc. > in the quickfixes branch, either, although that one did have a tree. > Is that expected? I think that's a difference between "bzr pull" (done on the trunk) and "bzr merge" (done on the branches), though I'm not really sure. Juanma ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2009-12-31 20:49 UTC | newest] Thread overview: 37+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-29 7:43 Strange message from "bzr pull" Eli Zaretskii 2009-12-29 10:18 ` Juanma Barranquero 2009-12-29 10:30 ` Eli Zaretskii 2009-12-29 12:40 ` Juanma Barranquero 2009-12-29 16:24 ` Eli Zaretskii 2009-12-29 17:00 ` Karl Fogel 2009-12-29 18:10 ` Eli Zaretskii 2009-12-29 18:13 ` Juanma Barranquero 2009-12-29 18:34 ` Eli Zaretskii 2009-12-29 19:28 ` Óscar Fuentes 2009-12-29 19:51 ` Karl Fogel 2009-12-29 20:04 ` Óscar Fuentes 2009-12-29 20:15 ` Karl Fogel 2009-12-29 20:29 ` Eli Zaretskii 2009-12-29 23:32 ` Óscar Fuentes 2009-12-30 4:16 ` Eli Zaretskii 2009-12-30 5:15 ` Óscar Fuentes 2009-12-31 9:39 ` Stephen J. Turnbull 2009-12-29 20:16 ` Eli Zaretskii 2009-12-29 23:14 ` Óscar Fuentes 2009-12-30 4:21 ` Eli Zaretskii 2009-12-30 4:28 ` Miles Bader 2009-12-30 5:26 ` Óscar Fuentes 2009-12-29 18:44 ` Karl Fogel 2009-12-29 19:01 ` Eli Zaretskii 2009-12-29 19:09 ` Karl Fogel 2009-12-29 20:09 ` Eli Zaretskii 2009-12-30 7:02 ` Eli Zaretskii 2009-12-30 12:19 ` Juanma Barranquero 2009-12-30 15:05 ` Eli Zaretskii 2009-12-30 15:19 ` Juanma Barranquero 2009-12-31 19:36 ` Karl Fogel 2009-12-31 20:49 ` Juanma Barranquero 2009-12-29 21:37 ` Stefan Monnier 2009-12-31 9:43 ` Stephen J. Turnbull 2009-12-29 18:02 ` Eli Zaretskii 2009-12-29 18:12 ` Juanma Barranquero
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.