Re: Bug statistics

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Would using "bzr ci --local" for several changes, followed by a single
 > "bzr push" help here?

Probably, but it gets messy after a while, because of the likelihood
of concurrent changes to the master.

 > Would it do any harm to the master repository?

Yes, it might.  It needs checking.  I *think* that in a bound branch
the upstream repo is considered authoritative, so that with the
following history

Local                Upstream
0 -- A*              0 -- B -- C*

pulling from upstream gives

Local                Upstream
0 -- B -- C* .. D        0 -- B -- C*
  \           .
   \         .
     A ......

with Local in a "pending merge" state that will result in D when
committed, and A on a side branch.  This is good; on pushing
Upstream's mainline has been preserved.

The potential damage is that if the Local changes are considered
authoritative, the catch-up merge from Upstream gives

Local                Upstream
0 -- A* ...... D        0 -- B -- C*
  \           .
   \         .
     B -- C .

and as you can see the old mainline is about to get shunted off on a
branch, while A usurps a mainline position.

The problem is that "bzr help pull" sez:

  If branches have diverged, you can use 'bzr merge' to integrate the
  changes from one into the other.  Once one branch has merged, the
  other should be able to pull it again.

This suggests that to make things right you need to merge *from* Local
*into* Upstream, which means that you need to be able to run bzr on
Savannah.  Urk.  However, I *think* that I've heard that commits
created with commit --local are treated differently, but I can't find
any documentation of that offhand.  "bzr help update" also suggests
that the wrong things may happen:

  This will perform a merge into the working tree, and may generate
  conflicts. If you have any local changes, you will still need to
  commit them after the update for the update to be complete.
  
  If you want to discard your local changes, you can just do a 'bzr
  revert' instead of 'bzr commit' after the update.
  
  If the tree's branch is bound to a master branch, it will also
  update the branch from the master.

However, in old Arch terminology, an update was actually a rebase of
local commits on top of the upstream branch, which is exactly what you
want here.

Bottom line: maybe commit --local does exactly what you want, but it
should be checked before recommending it.