Re: Locks on the Bzr repository

[Uday S Reddy]

Eli Zaretskii writes:

> Well, Stephen refused to tell more, citing my imaginary unwillingness
> to know.  (Since when asking a question means you don't want to know
> the answer?)  So I guess we will never know what Stephen was talking
> about.

Well, the strategies I mentioned are common knowledge.  If Stephen has
some other sophisticated tricks he knows about, I am sure he will tell
us.  

> Btw, pull is only possible when the branch didn't diverge from
> upstream, which means it is not suited well for a branch where you do
> development.  At least AFAIU.  I'm not even sure it will agree to do
> its job if you have uncommitted local changes.

Pull works before you commit.  It is the same as update, just a
difference in terminology.

If you commit wihout pulling first, then your branch may begin to
diverge from the public repo.  A bound branch won't allow you to do
this.  It will force you to update first.  So, I can see a reason why
the Stefan and Yidong might recommend bound branches.  But the
reasoning is weak.

If I do 

  commit
  push

and the push fails because the branch has diverged, then my strategy
is to 

  uncommit
  pull
  commit
  push

So, for a single commit, you can get the same effect as bound
branches.

If I do multiple commits to my branch and it has diverged
significantly from the public repo, then I do

  rebase
  ... resolve conflicts
  ... test
  push

(Even though you said you understand how rebase works, here is a quick
summary.  If you originally pulled at revision 500, and made commits
501..505 while the central repo moved up to revision 510 in the
interim, then doing a rebase will import revisions 501..510 from the
central repo and move your commits to 511..515.

This has a significant advantage over bound branches.  I am able to
use my main branch as if it were a task branch, keep all the related
commits together, test all of the commits together, push at my own
convenience, reduce the time wasted in synchronization and ensure that
all the commits are at the top level of the history.  (Bound branches
do the opposite.  They intersperse your commits with others.  You
might end up publishing your commits before they are fully tested.
And, they force you to synchronize with the central repo for each
commit.  In essence, bound branches are not distributed.  They are
centralized.)

> Merging into a local branch is what I had in mind, and the
> disadvantage with the "bzr log" output I talked about applies to that
> workflow.  To me, it is a significant disadvantage: I use "bzr log" a
> lot, and it is painfully slow with the -n0 switch.

I understand.  If you use unbound branches, you don't have to do
this. 

> For the first kind, it is IMO not very good to have the changes
> uncommitted upstream for prolonged periods of time, because people are
> using the development code, and the bugs annoy them.  So you'd like to
> commit those to upstream frequently.  And if you commit frequently,
> the proposed rebase-push workflow (IIUC) is not a real improvement,
> perhaps even a nuisance, because it adds the overhead of the rebase
> and does not save me from frequent slow commits to the master
> repository.  And if your local commits have bug-fixes and new features
> interspersed, and you want to commit just the bug-fixes, won't the
> workflow you need for such cherry-picking become even more
> complicated?

Commiting/sychronizing "frequently" is still better than commiting
instantly.  It gives you a choice as to how frequently you
synchronize.  That might depend on the urgency of the fixes and server
contention levels.  Bound branches remove that choice.

The overhead of rebase is also part of the choice.  In cases where the
overhead is significant, you might push more frequently.  In cases
where it isn't, you might push less frequently.

As for interspersing bug-fixes and new features, I would pick and
choose depending on the situation.  A half-finished new feature
sitting in the trunk doesn't hurt anybody.  I might leave it in.
(People are expected to use the new feature only after it gets into
the NEWS file.)  Or, if I don't feel comfortable about it, I would
probably push my current main branch as a task branch, reset the main
branch to the old state (using uncommit), and attend to the urgent bug
fix in the main branch.  Or, I might do the urgent bug fix in a new
mirror of the central repo and push it.  It will then reappear as part
of rebase in my main branch.  So, there are lots of ways of doing it.

As I said, for big new features, I would use separate task branches. 

> For the second kind of changes, I don't see how doing that on an
> unbound "mirror" branch is different from a separate branch whose
> purpose is development.  A separate branch has the advantage of
> keeping the development separate from mainline, so I cannot by mistake
> commit unfinished code to upstream.  It also lowers the mental burden
> on my mind, by keeping things spatially separated.  Merges are
> painless either way; I generally find bzr doing its job very well when
> I merge.

Agreed.

> So bottom line, I see no advantages to using an unbound branch which
> mixes changes of different types.  I agree it's probably possible to
> do all that with an unbound branch, but I don't see how it would
> relieve the pain of slow commits and slow updates/merges from
> upstream, which both are slow due to network traffic bzr incurs when
> it uses SFTP.

Ok, here, once again are the advantages:

1. Allows you to synchronize with central repo less frequently.

2. Allows you to choose when to synchronize.

3. Keeps your related commits to the mainline together.

4. Allows you to go from bug-fixing mode to (small) development mode
and back, without much pain.

5. Allows you to choose between many different workflows, and even to
switch from one to the other on the fly, whereas bound branches seem
to allow only one workflow.

> Well, you see, for me, "a few days worth of work" means in practice a
> few weekends of work, because I have almost no time on weekdays for
> any significant work.  A week's worth of commits to upstream by others
> is most of the time significant enough to make it a PITA when you have
> local changes, because there isn't a week that I don't find some small
> bug I want to fix and commit almost immediately, to let others enjoy
> the fix.

Ok, I understand.  Most of my work is done during weekends as well.
If I am in a bug fixing mode, I might work on several of them in a
day, but perhaps synchonize only once in the day.  

> Why would you say that?  That's not true.  Nothing prevents me from
> editing while "bzr ci" churns away.  The system is not locked, only
> (some) bzr operations will fail.  But most of the development is not
> about bzr ops, its about using the editor, the compiler, and other
> development tools, none of which are locked up when "bzr ci" runs.

Ok, I stand corrected.  I don't have experience with long-running
commits.  

> Seems you think that when I'm done with developing one feature or
> bug-fix, I immediately proceed to committing the next one.  But that's
> not so, at least not here.  Before I'm ready for the next commit,
> either locally or to upstream, I need to develop and test it.  And
> that part, which is what I do most of the time, is not blocked by a
> running commit.

Agreed.  It is not that the synchronization itself might be blocking
you for further commits (although Jason might be in a situation where
that happens as well).  But, when you want to synchronize, you need to
resolve conflicts which you may not be ready to do at that time.  You
can then postpone synchronization and continue working on other commits.

> I don't understand this argument at all.  In fact, I think it's plain
> false.  My workflow in a bound branch is this:
> 
>   brz up
>   [build the current upstream]
>   [some minimal sanity checks to make sure upsteam works]
>   [make changes]
>   [build and test the modified binary]
>   [repeat the sanity checks, fix anything that became broken]
>   [bzr up]
>   [if there are any changes upstream, build and test again]
>   [repeat last two steps until "bzr up" brings no changes]
>   bzr ci
> 
> Now please tell me how can I commit code that is "untested and unsafe"
> with this workflow?  What am I missing?

I agree that you are being very disciplined here.  But, most of us
think of update/pull/rebase as just a chore to get through before we
can push/commit.  Only if it gives rise to merge conflicts would we
think there is need for further testing.  So, the more
update/pull/rebase we have to do, the more unsafe the code is.  But,
how much this is a problem in reality will probably depend on the
project and the nature of changes being made.  I don't have a lot of
experience here.  But it is a concern, and it got raised for me only
after reading Stephen's message.

> For the record, I didn't write the recommended workflow (I don't even
> use it to the letter).  It was written by 2 people who know a lot
> about Bazaar and dVCSs.  So I trust them to have weighed the merits
> and demerits when they decided on that workflow.

Ok, for the record, I don't mean you by saying "you".  I mean the
emacs-developer team in general.  It seems to me that the closeness to
the previous workflow using CVS was perhaps the overriding criterion
for the authors of the recommended workflow.  The technical merits and
demerits were probably not at the top of the scale.

Having always used unbounded branches, I came into this discussion
wanting to learn why bound branches are being used by you guys.  I
still don't know why.  But I can see that it makes you feel a lot more
comfortable. 

Cheers,
Uday