[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 20:46:37 +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:52 PM, Hendrik Boom wrote:
> 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.
That asks for the ability to commit a change to a different branch than
what you're working on - but without bringing in the entire ancestry.
Somewhat similar to pluck. I certainly found myself in situations where
I wanted that feature, before.
Sometimes I commit on the "local-adjust" branch and then pluck that to
the devel branch. That may lead to issues with subsequent merges, though.
> 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.
To me, that still sounds prone to error. I don't like VCS controlled
scripts to (try to) control the VCS. That's a loop asking for trouble, IMO.
> I don't even think there's a mechanism for forbidding a single
> changeset to propagate.
There isn't.
> I do wish there was.
My point was: I do not even wish there was. IMO (light-weight) branches
are perfectly fine for these kind of things. What we need instead is
better manageability, so that in the given example, you wouldn't have to
switch forth and back.
> Hmm. Another possibility is for the Makefile -- or whatever else -- to
> conditionally include a separate local-options file -- conditional on
> there being one.
Sure, whenever that's possible, go for that.
I encountered a similar scenario when working on two features, let's
call them A and B. I work on each of them in a separate branch, but
before landing any of the two, I like to check the combination thereof.
Easy, I do an explicit_merge.
However, in the combined branch, I now find bugs. Those are much more
likely in the combination, but really are bugs in either feature A or B.
So I start working and testing on the combined branch. Still, I want to
commit my changes to either feature A or feature B.
Regards
Markus Wanner
signature.asc
Description: OpenPGP digital signature