[Top][All Lists]

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

Re: [Monotone-devel] Re: How will policy branches work?

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Re: How will policy branches work?
Date: Tue, 12 Feb 2008 13:54:09 +0100
User-agent: Mozilla-Thunderbird (X11/20080109)

Hello Nuno,

Nuno Lucas wrote:
The ideal (in an academic view) source code has the maximum
independence possible between source files, so one can achieve maximum
re-usability. So every source file can be thought as an internal
library (a black box) for the rest of the program.

It's when you group a set of related source files that you actually
call it a module, but they usually stay as independent as before.

I'm not a big fan of a very large number of branches. One can get lost
in too many of them, and over time they become un-mergeable. While it
can be normal for that to happen in a big team, that is not desirable
(IMO) when you can avoid it.

That argument applies as well to multiple heads per branch. Those are even called micro-branches sometimes. They are certainly branches of development in the DAG.

To me, these micro-branches are major achievement of distributed VCSes. I really enjoy that, because I can focus on the work I want to do at the very moment, instead of being forced to do something else (merging, updating, re-testing, etc..).

From that point of view, what we call branches in monotone is just a nice way to organize all the heads of development. Merging between them is just as easy and straight forward as merging multiple heads in the same branch: you are merging two revisions, which were derived from some common ancestor.

So yeah: branches are really inexpensive. Use them extensively!
(But don't forget to merge often enough, it's not that hard either.)

Are you really sure I should have a branch for every file which I
consider as independent from the rest? And even if only on internal
modules, a non-trivial GUI project can have dozens of them.

I would argue, that you naturally have as many heads (branches), as you have developers in a team. Because each and every developer has its own line of thinking. Having one per file doesn't seem very useful to me, because experience tells me the above assertion is way too academic ;-)

Of course, the developers also need to coordinate their work. They need to discuss and reach an agreement on who works on what. But that's not a thing where monotone can be of much help. Ordinary meetings or Skype or pretty much every collaboration suite is a better tool for that job, than monotone.

The developers are normally eager enough to merge their changes often enough, because they want to see their work landing on mainline (in monotone speech). If they coordinate well enough, merging is pretty automatic. Try it, and you will soon drop the fear of branching and merging.

To me, cherry picking has to do with accepting (picking) changes from
other developers or other branches, which I like (the cherries), but not
the ones I don't.

Using branches for that is more trouble than it worths (the failed
merges problem becomes horrible on monotone).

Sorry, I'm not sure what you are talking about here. I fail to understand how you can "use branches" for cherry picking. Branches alone certainly don't solve the cherry picking problem. It's rather a problem of tracking history and merging correctly (for quite varying values of correctness).

I've never seen "failed merges" on monotone. I assume you meant manual merging, where monotone failed to merge automatically? As I'm considering cherry picking to be a manual merge per definition, I don't understand, how or what monotone could do better.

(If you really want to "cherry pick", I advice you start a new branch, and "pluck" in the cherries you want. That gives you a branch you consider to be good, something you can sign, push to others and propagate back to mainline (without possibly unwanted changes from the original branch). If you figure out later on, that you also need other changes, you can still pluck from there and commit on top of that intermediate branch, which then features the same changes, but possibly in a different order. Whatever that's worth.)



reply via email to

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