[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Forbid a changeset from merging
From: |
Hendrik Boom |
Subject: |
Re: [Monotone-devel] Forbid a changeset from merging |
Date: |
Thu, 15 Aug 2013 08:52:12 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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