Bazaar

send always returns Bundling 0 revision(s)

Asked by Bruce Mutton

I assume this is a basic misunderstanding due to my lack of familiarity with versioning concepts in general...

I can create repositories, and multiple branches, add, diff, ignore, merge, commit, uncommit, revert etc and have been using these for the development of a text based project. i can share it across a couple of computers using 'branch' via usb flash memory physically transferred between the machines. I think that for a beginner I am almost comfortable with the above actions.

I have dabbled with launchpad briefly and it seemed to work, but the project I am working on is not mine to make public domain.

What I want to do is to share my bazaar repository with a couple of computer users via patch files / email. (I've had even less success with ftp)

Every time I use the send command I get;

"Bundling 0 revision(s)."

I presume this means the patch contains no data, as when i try to apply it with merge, I get something to the effect - no changes to apply.

i presume the submit branch for 'send' has the same meaning as it has for 'merge'.
I cannot decipher exactly what the public branch is for or if it is required, but any of my presumed 'sensible' interpretations make little difference to the outcome.

Any idea where I am going wrong?

A transcript of a typical patch file follows. It appears as though it may contain data, but, as above, I am unsure;

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: <email address hidden>
# target_branch: C:/Documents and Settings/Bruce/My\
# Documents/Bruce/Outdoor/Cave/Therion Data and\
# Notes/th_RiwakaCaveSystemData/trunk
# testament_sha1: 347c4b794e0ac174624945bba66efde187039f02
# timestamp: 2010-05-27 22:01:41 +1200
# source_branch: C:/Documents and Settings/Bruce/My\
# Documents/Bruce/Outdoor/Cave/Therion Data and\
# Notes/th_RiwakaCaveSystemData/trunk
# message: submit AblutionEdits rev 23 to trunk
# base_revision_id: <email address hidden>
#
# Begin patch
# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdjgvvgAABJfgAAQQGFxUBIA
AACv794QIABkRTaajamQyGjTaRiFGgBMBBkwQhDmaVnH5r9hMFQyJ7EUzThiw4Ixc/mQVpexbPS2
9yLLTxaFbWvXcN2zcydOQxpD652acQC4g4Z96jI5BipgKAAiM5Zz45Kd/4u5IpwoSGxwX3wA

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Parth Malwankar
Solved:
Last query:
Last reply:
Revision history for this message
Parth Malwankar (parthm) said : 		#1

Hi Bruce,

If there is any difference between the current branch and the target branch then the number of revs to be sent show up as revision count. Could you share the exact command that you have tried running? In your patch, the source_branch and target_branch show up as the same.

Typically you would need two branches to use send. In the example below one is the mainline (trunk) and the other is a bug fix branch. So the bug fix branch has 8 revs that the target branch does not have. The submit branch defaults to the parent. In case of the example below, I would have done 'bzr branch trunk 501307-init-recursive-scan' at some point. I could have done 'bzr send -o -' to the same effect as 'bzr send ../trunk -o -'. Typically the submit_branch is maintained as a mirror of the public branch. So in the example below, I won't really directly add versions to trunk but I keep pulling changes from the host where the trunk is hosted. My patch would applied to the hosted trunk and I would then pull trunk.

I am not sure of specific use of public_branch argument, maybe someone else can comment on that.

For e.g.:

[501307-init-recursive-scan]% bzr send ../trunk -o -
Bundling 8 revision(s).
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: <email address hidden>-\
# faqc89yv2jl41q1j
# target_branch: ../trunk
# testament_sha1: ef9f6646bf31a6d0d2505ccd34b98ec5829c8313
# timestamp: 2010-05-29 21:19:45 +0530
# base_revision_id: <email address hidden>
#
# Begin patch
=== modified file 'NEWS'
--- NEWS 2010-05-28 03:56:25 +0000
+++ NEWS 2010-05-29 04:06:44 +0000
@@ -20,6 +20,10 @@
.... snip ....
                 pb.update("Building tree", num - len(deferred_contents), total)

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWaxBdNYADGl/gABUQABYd//3
WyPcjv////BgD859NxOOh0VRVVSRplJRRi7mbKw2S2rd3QoA0LpjooSSCU/UyZJjSbRPImjEyEZD
... snip ...
uMklvcg7/PTf3xJFTekdkfVGyM/04qyJc4jYIxWLCwine4zCZMCZA9kKIdwia4cE2R+ThtCuw+qN
JL//xdyRThQkKxBdNYA=
[501307-init-recursive-scan]%

Revision history for this message
Vincent Ladeuil (vila) said : 		#2

'bzr send' aim is to produce a bundle containing the work you want to share.
In other words, the people receiving your bundle should be able to recreate your branch.
As such, a bundle can contain 0 revisions (they already have all the needed revisions and need
only the revid of your tip), all the revisions that constitute the history of your branch or subset between these two extremes.

But since you generally send this to people that already have a good part of the history of your branch, the bundle
generally contain only the missing revisions, generally the one(s) you created when working on some feature or
bugfix. It also contains a human-readable diff that represents the overall patch against the submit branch (conflating
all the contained revisions as needed).

'bzr' needs to know which history is known to both sides and the public branch *is* supposed to represent
this history known by both sides.

Revision history for this message
Bruce Mutton (dangle) said : 		#3

Thank you Parth & Vincent
I expect that information will help me out. I'll need some time to digest and experiment.
I will report back but it may not be for some days or a week...

Revision history for this message
Bruce Mutton (dangle) said : 		#4

OK, I have tried;

bzr send "C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/AblutionEditsBranch" "C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/trunk" --mail-to <email address hidden>

and this created the patch file, named AblutionEditsBranch-23.patch as follows;

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: <email address hidden>
# target_branch: C:/Documents and Settings/Bruce/My\
# Documents/Bruce/Outdoor/Cave/Therion Data and\
# Notes/th_RiwakaCaveSystemData/trunk
# testament_sha1: 347c4b794e0ac174624945bba66efde187039f02
# timestamp: 2010-06-01 08:43:14 +1200
# source_branch: C:/Documents and Settings/Bruce/My\
# Documents/Bruce/Outdoor/Cave/Therion Data and\
# Notes/th_RiwakaCaveSystemData/trunk
# base_revision_id: <email address hidden>
#
# Begin patch
# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdjgvvgAABJfgAAQQGFxUBIA
AACv794QIABkRTaajamQyGjTaRiFGgBMBBkwQhDmaVnH5r9hMFQyJ7EUzThiw4Ixc/mQVpexbPS2
9yLLTxaFbWvXcN2zcydOQxpD652acQC4g4Z96jI5BipgKAAiM5Zz45Kd/4u5IpwoSGxwX3wA

I realise I must have a basic conceptual misunderstanding.
The send command asks for SUBMIT_BRANCH and a PUBLIC_BRANCH, whereas the patch file created echoes a TARGET_BRANCH and a SOURCE_BRANCH.
Is this a case of fuzzy terminology? Do they describe 2 concepts with dual descriptors or 4 concepts?
Is there a labelled diagram or picture somewhere that illustrates these concepts (and others)? This may reflect badly on me, but I have to admit that I have not yet found definitions that make complete sense.

I have made a rule for myself, that seems to work for all the other commands, that I always run command-line bzr and tortoise bzr from the folder (or working tree representation of the branch) that the command will act on or change. I have presumed the send command does not change a local branch, so I run it from my branch (trunk) that represents the remote persons branch (trunk) that will be changed (if it all works out as planned). This would make it consistent with the merge command (which works exactly this way for me) when used with all the branches local to my machine.

"The submit branch defaults to the parent." seems to be the opposite to the above, and perhaps points to the root of my misunderstanding.

Parth, if I interpret your comments correctly, you are suggesting that I should update the remote trunk from my local feature branch BEFORE I then update my local trunk by pulling changes from the remote trunk.

I don't think I can do this because we do not have a copy on a server accessible by sftp etc. Is not the purpose of the send command to allow us to share via email using a distributed model?

Very sorry if I am over complicating this or wandering off on the wrong track completely. Please bear with me. Perhaps a picture illustrating how the command line path arguments represent parts of working trees/branches on local, remote and host machines would help.

Revision history for this message
Bruce Mutton (dangle) said : 		#5

OK! I have managed to create a patch file that contains two revisions. I have merged the patch file and committed it locally, but have yet to confirm I can do that on a remote machine.

From my (small) success and looking at the contents of the patch, I infer that the SUBMIT_BRANCH is the 'path to the local working tree root' of the branch that the changes will be submitted to on remote machines (the trunk(s) in this particular trial), AND that this becomes the 'target_branch' listed in the patch file, ie from the point of view of the recipient of the patch file.

That the default for SUBMIT_BRANCH = branch-wise (not folder-wise?) parent of the SOURCE_BRANCH now makes sense, assuming of course that I am correct in my deduction that the SOURCE_BRANCH is the branch that is the source of the changes that have been made, and is the branch from which the Send command would normally be run from..

So am I correct in postulating that the SUBMIT_BRANCH for the sender is the same as the TARGET_BRANCH for the recipient?

I might then guess that the PUBLIC_BRANCH is the server based copy of the above SUBMIT/TARGET_BRANCHes.

Once I've successfully merged (or not) on the remote machine I'll report back!

Revision history for this message
Best Parth Malwankar (parthm) said : 		#6

> OK!  I have managed to create a patch file that contains two revisions.
> I have merged the patch file and committed it locally, but have yet to
> confirm I can do that on a remote machine.
>

Thats good to know. One quick way of knowing if revisions would be
generated is to view the diff between branches. So for e.g. you have
project/trunk and project/fix-foo-bug and you are in fix-foo-bug, you
can do:
$ bzr diff --old ../trunk

If there you see a difference, then send should generate a patch and
a bundle.

> >From my (small) success and looking at the contents of the patch, I
> infer that the SUBMIT_BRANCH is the 'path to the local working tree
> root' of the branch that the changes will be submitted to on remote
> machines (the trunk(s) in this particular trial), AND that this becomes
> the 'target_branch' listed in the patch file, ie from the point of view
> of the recipient of the patch file.
>

Yes. thats correct.

> That the default for SUBMIT_BRANCH = branch-wise (not folder-wise?)
> parent of the SOURCE_BRANCH now makes sense, assuming of course that I
> am correct in my deduction that the SOURCE_BRANCH is the branch that is
> the source of the changes that have been made, and is the branch from
> which the Send command would normally be run from..
>

This is correct. Parent is the branch you branch from.
For e.g. if you only have trunk and you do:
$ bzr branch trunk bug-fix-foo

Then,
  trunk is the parent of bug-fix-foo
  trunk is the _default_ submit branch for changes done in
bug-fix-foo. You can override the default.
  bug-fix-foo is the source of revisions that will be added to trunk
  trunk is the default target.

> So am I correct in postulating that the  SUBMIT_BRANCH for the sender is
> the same as the  TARGET_BRANCH for the recipient?
>

Yes.

> I might then guess that the PUBLIC_BRANCH is the server based copy of
> the above SUBMIT/TARGET_BRANCHes.
>

Yes.

> Once I've successfully merged (or not) on the remote machine I'll report
> back!
>

Revision history for this message
Bruce Mutton (dangle) said : 		#7

Thank you Parth
That all makes me feel much better.

I have now successfully merged and committed the patch on a remote machine, but not without some antics along the way. I am assuming it is some sort of bug, or at least unexpected behaviour by bazaar.

Following is some sort of transcript of events and bzr messages...
Sorry about all the dirty laundry

START TRANSCRIPT

Received StdFilesBranch-27.patch in email.

Copied it to project directory. (same folder as trunk and other branches)

Using Tortoise Bazaar...
bzr merge ../StdFilesBranch-27.patch

Run command: bzr merge ../StdFilesBranch-27.patch --directory "C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data a...

- GreenlinkArea/StdFiles/
-D GreenlinkArea/StdFiles/Greenlink Explorer Ladder ENT 1980 large.jpg
-D GreenlinkArea/StdFiles/Greenlink Explorer Ladder ENT 1980 small.jpg
-D GreenlinkArea/StdFiles/Greenlink Explorer Ladder ENT 1980.tif
-D GreenlinkArea/StdFiles/LayoutAtlasPaperSizes.thc
-D GreenlinkArea/StdFiles/LayoutScales.thc
-D GreenlinkArea/StdFiles/LayoutStandards.thc
-D GreenlinkArea/StdFiles/NSG logo.jpg
-D GreenlinkArea/StdFiles/NSG logo.png
-D GreenlinkArea/StdFiles/NZSS Logo.jpg
-D GreenlinkArea/StdFiles/NZSS Logo_large.jpg
-D GreenlinkArea/StdFiles/grades.th
 M GreenlinkArea/greenlinkcave/LayoutMapThisCave.thc
 M GreenlinkArea/greenlinkcave/LayoutMapThisCaveElev290.thc
 M GreenlinkArea/greenlinkcave/LayoutMapThisCavePlan.thc
 M GreenlinkArea/middleearthcave/LayoutMapThisCave.thc
 M GreenlinkArea/perserverancecave/LayoutMapPerserverance.thc
 M GreenlinkArea/perserverancecave/thconfig-Perserverance.thc
 M GreenlinkArea/swissmaidcave/LayoutMapThisCave.thc
-D StdFiles/LayoutScales.txt
-D StdFiles/LayoutStandards.thc.~1~
-D StdFiles/LayoutStandards.txt

Conflict: can't delete GreenlinkArea/StdFiles because it is not empty. Not deleting.

bzr: ERROR: Unable to delete transform temporary directory C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/trunk/.bzr/checkout/pending-deletion. Please examine C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/trunk/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done.

On looking in the above mentioned folder there was a file (it’s name I forget) but on opening it with my favourite text editor it promptly vanished causing a “file not found” type of error.

On clicking ‘Retry’ I got

Run command: bzr merge ../StdFilesBranch-27.patch --directory "C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data a...

bzr: ERROR: Working tree "C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/trunk/" has uncommitted changes (See bzr status).

On checking I find that most (all?) of the changes in the patch have been applied to the trunks working tree, and the new files added are ‘non-versioned’.

So I try to Revert...

Run command: bzr revert StdFiles/LayoutScales.txt StdFiles/LayoutStandards.thc.~1~ StdFiles/LayoutStandards.txt GreenlinkArea/StdFiles Greenl...

bzr: ERROR: This tree contains left-over files from a failed operation.

Please examine C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/trunk/.bzr/checkout/pending-deletion to see if it contains any files you
wish to keep, and delete it when you are done.

Then

Run command: bzr revert StdFiles/LayoutScales.txt StdFiles/LayoutStandards.thc.~1~ StdFiles/LayoutStandards.txt GreenlinkArea/StdFiles Greenl...

bzr: ERROR: This tree contains left-over files from a failed operation.

Please examine C:/Documents and Settings/Bruce/My Documents/Bruce/Outdoor/Cave/Therion Data and Notes/th_RiwakaCaveSystemData/trunk/.bzr/checkout/limbo to see if it contains any files you wish to
keep, and delete it when you are done.

So I did this and then…

Run command: bzr revert StdFiles/LayoutScales.txt StdFiles/LayoutStandards.thc.~1~ StdFiles/LayoutStandards.txt GreenlinkArea/StdFiles Greenl...

+N GreenlinkArea/StdFiles/
+N GreenlinkArea/StdFiles/Greenlink Explorer Ladder ENT 1980 large.jpg
+N GreenlinkArea/StdFiles/Greenlink Explorer Ladder ENT 1980 small.jpg
+N GreenlinkArea/StdFiles/Greenlink Explorer Ladder ENT 1980.tif
+N GreenlinkArea/StdFiles/LayoutAtlasPaperSizes.thc
+N GreenlinkArea/StdFiles/LayoutScales.thc
+N GreenlinkArea/StdFiles/LayoutStandards.thc
+N GreenlinkArea/StdFiles/NSG logo.jpg
+N GreenlinkArea/StdFiles/NSG logo.png
+N GreenlinkArea/StdFiles/NZSS Logo.jpg
+N GreenlinkArea/StdFiles/NZSS Logo_large.jpg
+N GreenlinkArea/StdFiles/grades.th
+N StdFiles/LayoutScales.txt
+N StdFiles/LayoutStandards.thc.~1~
+N StdFiles/LayoutStandards.txt
M GreenlinkArea/greenlinkcave/LayoutMapThisCave.thc
M GreenlinkArea/greenlinkcave/LayoutMapThisCaveElev290.thc
M GreenlinkArea/greenlinkcave/LayoutMapThisCavePlan.thc
M GreenlinkArea/middleearthcave/LayoutMapThisCave.thc
M GreenlinkArea/perserverancecave/LayoutMapPerserverance.thc
M GreenlinkArea/perserverancecave/thconfig-Perserverance.thc
M GreenlinkArea/swissmaidcave/LayoutMapThisCave.thc
Conflict adding file GreenlinkArea/StdFiles. Moved existing file to GreenlinkArea/StdFiles.moved.

After this I went through and deleted all the backup files to get to a state where Diff & Add both indicated ‘no changes’.

Then again tried the Merge...

Success!!
Then checked Add, Diff
Then Commit & success!

END TRANSCRIPT

So I presume bazaar somehow got ahead of itself and checked for temporary files before the system could delete them? Or is it likely I did something wrong?

And on the topic of documentation.
As a complete newcomer to the concept of version control software I have had quite some difficulty understanding the concepts. I think this is because the documentation is written by people very familiar with the concepts and so the terminology is very loosely applied. This is probably not noticed by those already very familiar, but has certainly being completely dumbfounding for me - trying to decide whether the five similar descriptions refer to one concept, two or three concepts, or five concepts. Much of the time i have been over complicating it, but as a newcomer i have had no way of knowing.
Otherwise, the command-line bzr documentation is generally quite easy to follow but the Windows Bazaar and Tortoise Bazaar is less so, and frustratingly uses slightly differing terminology, making it very difficult for a new comer to be sure they are performing similar actions in each of the user interfaces.

So unless they are over simplifications, perhaps something of my proposed 'definitions' that Parth commented on above could be incorporated into the documentation.
And for me an annotated diagram would be so much better than a descriptive paragraph.
I have drawn myself a picture of the folder/branch/user relationships to help me understand and communicate the send - merge process. If anyone is interested in using it as a basis for improving the documentation I can tidy it a bit, scan it and send it in. Any takers? Where to?

Revision history for this message
Bruce Mutton (dangle) said : 		#8

Thanks Parth Malwankar, that solved my question.