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

[Markus Schiltknecht]

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.)

Regards

Markus