"bzr push" to a bound branch without a working tree

John Arbash Meinel john at arbash-meinel.com
Wed May 18 09:20:33 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/18/2011 10:57 AM, Eli Zaretskii wrote:
>> Date: Wed, 18 May 2011 10:17:45 +0200
>> From: John Arbash Meinel <john at arbash-meinel.com>
>> CC: bazaar at lists.canonical.com
>>
>> If quickfixes is a lightweight checkout of trunk, and trunk is a bound
>> branch to upstream trunk, then committing in "quickfixes" will commit
>> directly to local trunk, which commits to remote trunk.
> 
> But quickfixes is not a lightweight checkout, at least AFAIK.  It was
> created by a "bzr branch" command without any switches.  I see both  a
> .bzr/branch/ directory and a .bzr/checkout/ directory there.

We always create .bzr/branch. In lightweight checkouts it is a
BranchReference which has ".bzr/branch/location". While a regular branch
will have .bzr/branch/last-revision and .bzr/branch/tags and probably
.bzr/branch/branch.conf.

> 
>>>     D:\usr\eli\bzr\emacs\trunk>bzr merge ../quickfixes
>>>     NoWorkingTree: No WorkingTree exists for "file:///D:/usr/eli/bzr/emacs/trunk/.bzr/checkout/".
>>>
>>>     Is this expected?  I don't think the documentation of "merge" says
>>>     anything about working trees.
>>
>> You have to have a tree to merge. Because we are merging the contents of
>> one branch into another, giving you an opportunity to commit. And
>> hopefully its obvious that you have to have a tree to commit.
> 
> No, it isn't obvious.  (I already asked a long time ago to have some
> detailed explanation of what each of these commands do to the tree and
> to the history.)  I thought that a tree-less branch has all the
> information about the files and the revision history in the branch
> meta-data.  E.g., I can "bzr diff" in the tree-less branch, and it
> works even though there's no tree with files to diff against.  Merging
> does not only merge the file contents, does it?  Committing certainly
> stores deltas from the new changes in the branch meta-data, doesn't
> it?  So, at least conceptually, a commit could work without files at
> all, by storing the necessary information in the meta-data.
> 
> I realize that I'm missing something important, but please point me to
> some documentation, if it exists, that would have prevented me from
> missing that.

...

>> 1) It doesn't make sense to push from a branch to itself, which is what
>> you are doing. Since quickfixes is a lightweight checkout *of* trunk,
>> pushing from quickfixes to trunk is pushing to itself.
> 
> But since it isn't a lightweight checkout, I don't think that
> consideration applies.

I'm pretty sure it is. We don't let you chain bound branches. So commit
in a bound branch of a bound branch would fail.

> 
>>> Is this configuration (a tree-less bound branch and its child local
>>> branch with a tree) supported?  If so, did I do something wrong?
>>>
>>> TIA
>>>
>>
>> It is perfectly supported.
> 
> So what would be a possible workflow in this arrangement?  Let's say I
> made a change in quickfixes and want to push it upstream, what should
> I do?
> 

You pushed it upstream by committing.

>> One thing that could have helped. Run "bzr log" in trunk, and notice
>> that your commit is already there.
> 
> I perhaps would have thought of that if bzr would tell me something
> along the lines of "revision NNN is already here".  But how could I
> possibly have guessed that given the error messages shown in my OP?
> The commit to quickfixes didn't say anything extraordinary, so I had
> no clue it had any effect except committing to that local branch.
> 
> Thanks.

It should have said something about "committing to branch ..." which
should have said the revision was being committed to "D:.../trunk".

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3Tj2EACgkQJdeBCYSNAANkFgCggcL66gp4JZDTLktqWI5GrKPH
+p4AoLaMQWBaIcQVNrvA6P2gcGD5ey3E
=bAJl
-----END PGP SIGNATURE-----



More information about the bazaar mailing list