monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] automate sync display branches?


From: Thomas Keller
Subject: Re: [Monotone-devel] automate sync display branches?
Date: Sat, 11 Sep 2010 23:59:45 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b3pre Thunderbird/3.1.3

Am 11.09.10 22:12, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
>> Am 11.09.10 18:09, schrieb Stephen Leake:
>>> Stephen Leake <address@hidden> writes:
>>>> Hmm. I could have DVC specify a set of hooks that are loaded for all
>>>> automate stdio sessions, not just for sync commands. That should work.
>>>
>>> But it doesn't. Using "io.stdio:write(...)" from a Lua hook does _not_
>>> send the data to the stdio main stream. Which I knew, but forgot
>>> temporarily.
>>>
>>> So I need to write some C++. I'll use the nvm.stephe branch.
>>
>> Please use a separate branch - maybe "underneath" nvm.stephe - for
>> features like that. It will make the review and identifying things later
>> on much easier.
> 
> How does it make it easier? 
> 
> If you check it out now, you can track changes in it easily.

Its simply not a good idea to mix different features which do not belong
together in one and the same branch, both for the source and the target
branch's history: The later merge you're doing will simply say nothing
about _what_ was merged - or will you remember later on for what
nvm.stephe stood back in the day?

> If you decide at some later point to review all the changes related to
> this, you checkout nvm.stephe, do mtn log, and look for 'automate stdio
> sync'.
> 
> If the branch had a unique name, you would still have to look for the
> point where it branched from main.

Not anymore - having updated to the features head revision, `mtn log
-rlca(h:;h:net.venge.monotone)` is enough, which will not work with
unrelated, unmerged changes in that branch.

> There is quite a bit of overhead for a branch. Not so much in the db,
> but in the build environment.
> 
> This is likely to be a very short-lived task.

This is not a good excuse - if the feature is not something smallish
which could directly committed (as single revision) to nvm, it deserves
a separate public branch. If you don't want to go down that route, keep
nvm.stephe a private (unpushed) branch and send a completepatch upon
completion to the list, which could directly be applied to nvm after
review.

Thomas.
-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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