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

[Markus Wanner]

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