[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locks on the Bzr repository
From: |
Lluís |
Subject: |
Re: Locks on the Bzr repository |
Date: |
Tue, 24 Aug 2010 14:37:19 +0200 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/23.2 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
Stephen J Turnbull writes:
> Uday S Reddy writes:
>> 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.
> Not at all. I'm not sure if Eli would do a "one-commit" patch in a
> separate workspace, and then merge, but he's said several times now
> that he uses multiple workspaces, at least for feature branches. It's
> certainly possible to have a "feature branch" for a one-line patch.
> So you put your change in a separate workspace and test it there. You
> merge when you're happy with it. This is nicer with rebase, I admit,
> but it's not impossible without it.
Just to make sure I understand it. Suppose I'm working on a branch with a fairly
large set of changes and it has been merged back to trunk. After a while a bug
is found on my code, which was not thoroughly tested, or a new relatively minor
functionality is added related to the code on my branch. Should this be
committed on my branch and then followed with a merge to trunk? Or should this
live in a completely new branch that will be merged back to trunk once it's well
tested?
Now that I think of it, I think I start to see the reason for nested history and
the suggestion of not using rebase. Even for the smallest bug fix or feature
addition, a full branch should be created, and every change should be thoroughly
tested in there. Then, trunk would be composed of just merge messages like "add
subsystem Y", "add feature X to subsystem Y", "fix bug N on Y". This would
produce a log in trunk that would very closely resemble the contents of a NEWS
file, but at the expense of a strict branch/test/merge discipline, which is not
bad per-se.
Lluis
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth
- Re: Locks on the Bzr repository, (continued)
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/24
- Re: Locks on the Bzr repository, Karl Fogel, 2010/08/24
- 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, 2010/08/23
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/24
- Re: Locks on the Bzr repository,
Lluís <=
- 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
- Re: Locks on the Bzr repository, Uday S Reddy, 2010/08/24
- Re: Locks on the Bzr repository, Lluís, 2010/08/24