local commits

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Really no answer to this one?
Den 30/01/2011 11.22 skrev "Launchpad Janitor" <
<email address hidden>>:
> Your question #141484 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/141484
>
> Status: Open => Expired
>
> Launchpad Janitor expired the question:
> This question was expired because it remained in the 'Open' state
> without activity for the last 15 days.
>
> --
> If you're still having this problem, you can reopen your question either
> by replying to this email or by going to the following page and
> entering more information about your problem:
> https://answers.launchpad.net/bzr/+question/141484
>
> You received this question notification because you are a direct
> subscriber of the question.

Local commits are *never* exterminated.

If you do an update with local commits, a merge is performed, your local commits then become pending merges.

Look at 'bzr st -v' or use 'bzr qlog' to see them.

In fact no commit is ever exterminated, it is still present in the repository even if it's not part of any branch history anymore, it's then called 'dead' and 'bzr heads --dead-only' will list all such dead commits ('heads' is part of the bzrtools plugin).

You can then restore a working tree of this "dead" revision with 'bzr pull -rrevid:<dead_rev_id>'.

Den 30/01/2011 12.25 skrev "Vincent Ladeuil" <
<email address hidden>

> If you do an update with local commits, a merge is performed, your local
> commits then become pending merges.

OK!

So as a general rule, the revision history of bound branches must be
identical to the revision history of the server, from the point in time
where they became bound? Where can I read more on these rules?

Jon.

> If you do an update with local commits, a merge is performed, your local
> commits then become pending merges.

also, how do I then initiate a merge between my updated local repo and these
pending local merges?

> also, how do I then initiate a merge between my updated local repo and these pending local merges?

This happen when you do a 'bzr update' and you have local commits, doing 'bzr st' will list the pending merges.

> So as a general rule, the revision history of bound branches must be identical to the revision history of the server, from the point in time where they became bound?

When a branch is bound, it's updated in sync with its master (the commit happen first on the master and then the local branch is updated).

It seems that command 'bzr pull -rrevid:<dead_rev_id>' does not work to revert to local revisions. But apparently you can do it with the 'bzr revert' command. You just have to supply the revision number of the relevant local commit.

It seems that getting to know that the right revision number is not so easy, you can't do it with 'bzr log' or 'bzr st -v' or 'bzr glog'. You have to use 'bzr qlog' and click the plus sign on the merge point right after the local commits.

What does the "pending merges" (in_plural_) really mean? Is a merge not always performed only on the current/latest revisions of branches? Does the merging algorithm merge the oldest local commit firstly and then second local commit and so on?

A bzr working tree has 0 or more parent revisions (most commonly 1). When you commit in that tree, those revisions become the parents of the new commit.

bzr status 'pending merges' shows the revisions in the second and later parent revisions. By default it just shows the tip revision; with -v it shows all unmerged revisions.

Ok

So, being a pending merge is not an explicit property of revisions - rather it is a notification to users that they will probably want to merge the post-commit content of the working tree with one of the locally committed revisions?

Pending merges are only a property of the working tree.

They're shown in 'bzr status' to inform you that when you commit, you'll be committing a merge of those revisions.

When you see them there, the content in the tree has already been merged. Conflicts will be flagged if there are any. You may wish to check using 'bzr diff' or by looking at the tree that the merge was satisfactory. Other than that you don't need to do anything.