[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locks on the Bzr repository
From: |
Uday S Reddy |
Subject: |
Re: Locks on the Bzr repository |
Date: |
Mon, 23 Aug 2010 13:41:13 +0100 |
Stephen J. Turnbull writes:
> This is not true in general. In particular, the workflow suggested in
> BzrForEmacsDevs can produce a "clean history"[1] without rebase,
> although it may require remerging branches before pushing because of
> the race condition.
Yes, the current workflow does achieve clean history, but at the cost
of removing any gestation period for fixes that the developers might
want. I am surprised that many emacs developers are ok with it, but
my own experience is that a few days of testing through daily use is
necessary for me to develop confidence in some of my fixes. I would
feel very exposed if I can't commit fixes to my branch without
publishing them at the same time.
> > Bazaar's solution is to provide merge, which lumps each batch of
> > fixes together into a subhistory without concern for any logical
> > coherence among the changes.
>
> That is not a problem of merge. All VCSes provide merge.
No, I don't mean to say that merge itself is a problem. But, Bazaar's
recommendation to use merge *instead of* rebase is a problem. Bazaar
developers do seem to understand that merges doesn't give you a clean
history (at least in Bazaar's way of presenting history), but they
underrate its importance.
I am actually happy with Bazaar's presentation of history. A
straightline history is good for doing bisection when you need to.
The practice of hiding merge histories from the top-level is also nice
for ignoring unnecessary detail.
Moreover, I think that even normal merged branches would benefit from
rebasing. Otherwise, they involve a backwards time travel for the
initial commit, which is confusing during review and even worse when
you have to bisect for a change later.
Maybe I am one of those "users coming from central VCS tools with poor
merge tracking". But I don't see the new ways being necessarily
superior.
Cheers,
Uday
PS I am trying to keep this part of the thread focused so that Richard
has a coherent story to deal with.
- Re: Locks on the Bzr repository, (continued)
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/24
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/23
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/23
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/23
- Re: Locks on the Bzr repository, Uday S Reddy, 2010/08/23
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/23
- Re: Locks on the Bzr repository,
Uday S Reddy <=
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/24
- Re: Locks on the Bzr repository, Lluís, 2010/08/24
- Re: Locks on the Bzr repository, Lluís, 2010/08/24
- Re: Locks on the Bzr repository, Óscar Fuentes, 2010/08/24
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/24
- Re: Locks on the Bzr repository, Lluís, 2010/08/24
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/24
- Re: Locks on the Bzr repository, Lluís, 2010/08/24
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/24
- Re: Locks on the Bzr repository, Óscar Fuentes, 2010/08/24