Thomas Keller <m...@thomaskeller.biz> writes: > Am 11.09.10 22:12, schrieb Stephen Leake: >> Thomas Keller <m...@thomaskeller.biz> writes: >> >>> Am 11.09.10 18:09, schrieb Stephen Leake: >>>> Stephen Leake <stephen_le...@stephe-leake.org> 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?
That's what the checkin comments are for. There isn't anything else in nvm.stephe; I only use it for small projects that are not worth a whole branch, but are more than a single checkin. >> 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. That will work with my proposed flow as well, since there is nothing in nvm.stephe that has not been merged to main. I gather others keep stuff in a private branch that will never be pushed to main. I would find that confusing. >> 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 - Obviously, I disagree. But it's not worth fighting about. I'll use nvm.automate_sync -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel