Shortly: How can I take the latest revision (only) from a remote bazaar repository and add it as a new revision to a local repository.

Background: I have a development system and a production system. On a development system there's a bazaar repository having branch with lots of development revisions. Once in a while I want to incorporate the latest developments into production system. I want to do so by some sort of "pulling" (development system can not connect to production for security reasons, but production can initiate connection to development).

On the production, I don't want the whole development revision history, only those revisions which actually go into production (normally it's the branch tip). Yet I want version control on the production system to keep track of what actually goes into production each time.

bzr pull pulls the whole branch. bzr pull --revision=last:1 also pulls the whole branch, up to the specified revision.

bzr merge --pull --revision=last:1 also pulls the whole branch. bzr merge --pull --revision=last:2..last:1 and bzr merge --pull --change=last:1 both pull only the new changes introduced in the latest revision, but not changes introduced in the older revisions.

With lightweight checkout I have no track of revisions which are pulled into production - local working tree remains part of the remote repository

The only way I see so far is importing the working tree using some rsync or scp and committing them to a local branch afterwards. Any better ideas ?

  • I think git-pull does just what I need. Can anyone familiar with git confirm ? – Sandman4 Oct 28 '12 at 12:11

To some degree, you can do this by running:

$ bzr branch --stacked REMOTE-URL LOCAL-PATH

this will create a local branch that only has the last few revisions. It is an independent branch, so if you do a commit in the local branch, it won't automatically get pushed into the remote branch. If you try to access any data in the local branch that is not available, bzr will shell out to the remote branch to find that data.


First of all, you can't accomplish this by only pulling the last revision IMO, because each revision stores only the differences with the previous revision. That explains why for instance bzr merge --pull --change=last:1 doesn't work.

I would REALLY just pull the whole branch, but if you don't want this you could do something like

bzr diff -rx -p1

where x is the last revision you already included in production. This creates an overview of all changes between the current working directory and revision x, but without all the details of the revisions in between. The -p1 flag makes sure the output is in the patch format ( http://doc.bazaar.canonical.com/beta/en/user-reference/diff-help.html ). Then you can apply this patch on your production system.

I think it is ugly, but it might do the job.

  • Actually, revisions in Bazaar are snapshots, not differences. – janos Feb 6 '13 at 9:42
  • Yes, I know, so it is in git, but internally revisions are stored as delta differences. So your remark is just about terminology. The proposed solution is valid regardless, although I would not recommend using any of the solutions given here and just keep the revision history. – Gerhard Burger Feb 17 '13 at 16:31

If I understand correctly, you want to sync the production branch to the same state as the development branch tip, but without the revision history, right?

You can do that with:

bzr merge OTHER_URL
bzr revert --forget-merges
bzr commit

The result is effectively as if you have cherry picked the changes of all the missing revisions and committed them all at once.

However, there's a HUGE caveat here. Since the revision history is not preserved, Bazaar doesn't know that the changes you cherry picked have already been applied. The consequence is that next time you try these same steps, you will get conflicts. So I don't think this is a usable solution.

Another way (with a different caveat) is this:

bzr diff --new OTHER_URL | patch -p0

This will apply the diff of the current branch and the reference branch as a patch. The caveat here is that patch cannot handle renames.

All in all, I think what you're trying to do is strange. You should just pull or merge and keep the history. Or, you could try to work with feature branches. The thing about feature branches is once the feature is completed, you stop working on it. In which case, you can merge the entire feature branch and forget the intermediary revisions, because you will never merge from the feature branch again, so you won't have the double-cherry-picking problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.