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

[Nuno Lucas]

On Feb 10, 2008 10:57 PM, Markus Schiltknecht <address@hidden> wrote:
> Nuno Lucas wrote:
> > In this case you could say they are modules, but it could be a single
> > file on the source tree, with no clear separation between it and other
> > source files. You can't have a branch per source file (you could but
> > makes no sense).
>
> You can commit different changes to a single file in two different
> branches, so why do branches not solve your problem?

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.

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.

> > For me "cherry picking" is just what pluck does, but with an added
> > "unpluck" option.
> > That way you can try different patches, but have the option of
> > "un-applying" them, for example, while chasing some regression bug.
>
> Uh.. that reminds me more of quilt or mercurial queues, no?

Right, although I don't know mercurial.

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


Regards,
~Nuno Lucas