Re: Forbid a changeset from merging

On Thu, Aug 15, 2013 at 10:04:52AM +0200, Markus Wanner wrote:
> On 08/15/2013 02:22 AM, Hendrik Boom wrote:
> > II sometimes have to adapt a package to local conditions -- the most 
> > common kind of change is a configuration changem such as specifying where 
> > it is to be installed.
> > 
> > Now the obvious (and possibly wrong) is to make a local branch, make this 
> > change and propagate changes from the main branch into the local branch 
> > whenever it changes.
> > 
> > This works if there is a one-way flow of information from developers 
> > elsewhere to my localized branch.
> > 
> > But once the package has been adapted to local conditions, I will often 
> > want to continue developing it, using the local configuration.  I can't 
> > very well do this development on the main trunk, since it is not adapted 
> > to the machine I'm editing, running, and testing on,  So I have to do it 
> > on the local branch.
> 
> Understood.
> 
> > When the time comes, I'll want to propagate the changes to the main 
> > branch, but I won't want to propagate the local configuration changes to 
> > the main branch.
> > 
> > Is there any way to mark this one changeset so that it will never be 
> > merged into the main branch?
> 
> I usually use branches. They are cheep. Propagation can happen from a
> script. For example:
> 
> upstream
>   -> upstream.local-devel
>      -> upstream.local-devel.local-adjust

Well, this is more or less what I considered, but local-devel isn't all 
that easy to do without the local-adjust being applied during testing.
And as for editing in the local-adjust during testing and editing it 
out befure commit, well, that's bound to be error-prone.

Of course it would be posssible to do all the editing and static 
checking on upstream.local-devel and the propagate into 
upstream.local-devel-local-adjust before every test run...
Maybe even have the local-devel commit and local-adjust mtn propagate 
command in the Makefile for loocal-adjust.

Hmm.

> 
> It's getting a bit more painful if you do the local adjustment first.
> Then I usually end up with four branches:
> 
> upstream
>   +-> upstream.local-adjust   --,
>   '-> upstream.local-devel      v
>       '-> upstream.local-devel.local-adjust
> 
> Especially in case you keep modifying your local adjustments, merges can
> get a bit cumbersome, yes.
> 
> > Or am I approaching this issue entirely in the wrong manner?
> 
> In a way, branches are (part of) that tagging of how to merge. At least
> together with a script that remembers the ways to propagate between
> branches.
> 
> I don't think forbidding a single changeset in any other way is
> feasible. After all, you might eventually want to switch forth and back
> between the variant with your local adjustments and the one without.

I don't even think there's a mechanism for forbidding a single 
changeset to propagate.  I do wish there was.  As for switching back 
and forth, I can still use the local-adjustment branch as needed.

Hmm.  Another possibility is for the Makefile -- or whatever else -- to 
conditionally include a separate local-options file -- conditional on 
there being one.  Never check in that local-options file, even locally.
But there are enough tools whose input doesn't have any mechanism for 
this to make it awkward.

-- hedrik

> 
> Regards
> 
> Markus Wanner