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

[Nuno Lucas]

On Feb 6, 2008 6:46 PM, Markus Schiltknecht <address@hidden> wrote:
> Nuno Lucas wrote:
> > "Policy branches" aside, this is a feature it would be nice to have:
> > merge/propagate with path restrictions.
> >
> > A simple (and common) use-case is propagating/merging changes made in
> > a sub-directory (possibly a library, like sqlite in monotone repo) to
> > another branch.
>
> This would possibly leave us with a partly unmerged revision, no? Or
> would you want monotone to simply refuse merging, if there are files out
> of the path restriction which need to be merged? I'm not sure if I'm
> understanding your use case.

What's the problem with that? It is an independent library so any
other changes in other files have no relation with the changes we made
in that directory (or other restricted path).

The use case is just to isolate a bunch of "changesets" to a specific
part. It's up to the user to know what it's doing (monotone doesn't
know more than the user what the hell he is doing with it's
workspace).

It's the same to pick a large kernel patch (as an -rc1 patch) and use
filterdiff because we are only interested on the changes made to some
particular sub-system tree.

> For sqlite in monotone, we use a separate branch, from which we
> propagate to monotone mainline. Where it was 'merge_into_dir'ed, once
> upon a time, I guess. Isn't that sufficient for your case as well?

Bad example, then.

It's common for any non-trivial application to have separate
subsystems, like database-wrappers (independent on the real database
schema used), GUI wrappers (for portable graphics primitives), OS
function wrappers (like functions to scan a directory) , etc.

Any one of this sub-systems is expected to be independent of each
other (or depend on lower level sub-systems), but they are part of the
program and usually statically linked to it.

Some could be made into a generic library, but the usual case is that
they were made just for that application and are not generic enough
(meaning not enough features implemented) to be useful outside our
program.

When you branch an application to try something out it's normal you
add features to this internal libraries and latter drop the initial
idea. However, the features added to this internal libraries can prove
to be good enough to merge into the "trunk" (like when you found out
the changes needed to the main program are just big enough to be doing
now, but in the meantime you added a lot of functionality to the
helper libraries until you reach that conclusion).

The use-case is to "propagate" from that experimental branch just the
added features you had implemented. I would expect something like "mtn
propagate branch.testing branch.trunk "libs/*" would be enough.

Offcourse there are a lot of different ways to accomplish the some
thing, but it can be easier to the user if something so natural as
that could be done.

By the way, I don't see as this is any different than what is already
done by a 3-way merge with user editings. It's not the original
revision either.

Regards,
~Nuno Lucas


> Regards
>
> Markus
>