Strange message from "bzr pull"

Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Karl Fogel]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Óscar Fuentes]

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

Re: Strange message from "bzr pull"

[Karl Fogel]

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

Re: Strange message from "bzr pull"

[Óscar Fuentes]

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

Re: Strange message from "bzr pull"

[Karl Fogel]

Ó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!

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Óscar Fuentes]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Óscar Fuentes]

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

Re: Strange message from "bzr pull"

[Stephen J. Turnbull]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Óscar Fuentes]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Miles Bader]

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.

Re: Strange message from "bzr pull"

[Óscar Fuentes]

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

Re: Strange message from "bzr pull"

[Karl Fogel]

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.

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Karl Fogel]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

> 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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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

Re: Strange message from "bzr pull"

[Karl Fogel]

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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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

Re: Strange message from "bzr pull"

[Stefan Monnier]

> 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

Re: Strange message from "bzr pull"

[Stephen J. Turnbull]

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

Re: Strange message from "bzr pull"

[Eli Zaretskii]

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

Re: Strange message from "bzr pull"

[Juanma Barranquero]

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