emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]