monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Forbid a changeset from merging


From: Markus Wanner
Subject: Re: [Monotone-devel] Forbid a changeset from merging
Date: Thu, 15 Aug 2013 10:04:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

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

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.

Regards

Markus Wanner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]