Re: Forbid a changeset from merging

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

_______________________________________________
Monotone-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQQcBAEBCgAGBQJSDSINAAoJEOhoLRs/Memzp6ogAIMAgki7X9bxNTRSh5OAENTp
AoW1xhFwwhy8lH6hGoVK587wCDvywX7GJaJyUaRH2vuntQ/xo4iGUGxh96DLrfff
7ME3hdd1hcFXkRQTehD8vh22DbHAjIq51H2Cg0YXeXGNn0PU5c89AwyK1pK2hcGf
BWaQpzpmXSr2gZLBZlECbKmSv+357fPcBmN4xctyCEubr7YfQYY7rg59c8jSf5r7
/SGuvZaoULZErvsEV+pR4uyFIh09+11gFGIitiu3m0A2y7dny14MSWqOvLJVPEVw
UNKXR0SyV2WaJoiSN1ncgOv0+mBnmwW1KncYO9U/SatU049hO3vdyYKNh2FjJOSj
2j0KbiwzftHZkhY/NjGSr8O6puQAn+FqYimKCgQo0F5pK/+PO0wzaTMA7skB9EHC
65vEsvK0AzAWMT7RF1qiNz1sp8BZzin1qbqBcG1w/78xW26Iu4yj8gjXPGXJ3SZi
d3gBjeclChaH8g1JKxHWTxTXLU4oIDxIS8Ll2Tr52kR1zhDMoYtn+SqY75HA723e
mtFuB6CV3k/J5aH2bVoh6hdfPBa+SSp5BdC2b/8zJ8rhUZ2TGxaifzhiQfJoz9Pz
vwqzK6NVFXQlnfXp+izNb899p3D+YsbrgRypC9dpti6yTCtKq91esW2645aei/E8
wcS/nh/lQoCGl3xqAqUFnMa6T+ei6U0LYi0rLzMXbIfENmW0l8aeur0cR/RMgU0L
8YBI8u/d3OLrI5TUFzaOkOaG0Wiq/CAwAfuXRjUVUD78KZuy8r06G+vjTLHmq0r9
myDl+1E5Aj5MV4lm+8sQ3jf48LH4oyzdpt2r+9AtmwMYA7a5vrG5d07Bf21JuHSi
9hgYvdVqdkLuVjtFDb3gjuOCVh5SoS13oEm5HGcV7y5J145zbpP8RYLAhfARt28y
i/cv6fZcCPZu1NPdBJr3IQFysLZoHQ44L1/raZOaNeeNWn0CPC9eszggdxR1po4R
Yc6gFlT7I3mc4IMkc4FcZlrVfR+kfWoyLwnwv2ovSWhtoZkXokCCiuBLNyfbO/Ra
Yd+94M/GhDesVVPuBakND0SstXQdU1bgbNkFFTEdrJR7sxtPN7AHwrXbECiGURDg
4adBdgoVAMQaUQwctixH6DG650eIBHffQzmNhUIgP5s9kf8OhmwJ58ke9YIhm54O
quFjVOYlO/MTD5G3zPftVX1mjKeC6LLtYpaTqA4lSAy05fQtlCTyHNjw6DpwMoyM
qK5J45mHKdaB2phIH5ze+36SeqvX0hAoarcJKC13mNboTlAVeUgWulhA9Z8YQrag
MOyx8DLkNjaOcYTFZLhUjZndwhYcgp7yC4pDkAdrRH5mcLTlkMPvy6ENR3T4/Yw=
=m1YO
-----END PGP SIGNATURE-----