[IPython-dev] bzr - what am I doing wrong?

[Fernando Perez]

On Wed, Jun 4, 2008 at 8:25 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 6:13 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> Mmh, what if you have stuff in your local copy that you're playing
>> with still but not quite ready to commit?  I'm not sure I like the
>> idea that the local branch must be immediately gone after each commit.
>>  It seems to me that the iptrunk branch should be pretty 'pure' from
>> local work, but I do want a more long-lived area for local work.  Or
>> is this just 'going against the grain' of bzr workflow?
>
> For long-lived work you should have a separate "feature branch", e.g.
> "twisted-exp". Not "fernandos-stuff" where you routinely do all the
> local stuff and keep merging to it all the time.
>
> It's quite ok to merge stuff to your feature branches if it's a
> long-term undertaking, but for short lived fixes it's an unnecessary
> complication and should not be done "just to see if your stuff works
> with the new stuff". To test your branch against the latest codes, run
> the tests in trunk after "bzr merge ../ipfix", before commit.

But then how are those 'long lived' feature branches different?  If we
do merge into them, we're back to the history folding problem, no?  If
we don't merge into them, they diverge...

Basically (as Brian said) a basic feature of DVCS seems to be
precisely the ability to keep long (or short)-lived lines of work that
track the trunk and where experimental work happens, merging
nilly-willy the pieces that make sense and without having to worry
about the history.  Having to make a distinction between long and
short lived branches in terms of workflow for this point sounds weird.

I'm not saying there's no use for one-off branches, they're fine on
their own.  But I don't want to be constrained to that being the only
way to merge into trunk, that does feel unduly limiting...

cheers,

f