I try to merge:
hg me -r <some-revision>
and get:
<some-file>: ambiguous merge - picked m action
What does it mean?
This message comes from the merge code when it is handling a "difficult" merge, where there is no "best" lowest common ancestor (LCA) commit in the commit graph. (Instead, there are at least two LCAs—or exactly two in this case since it's tricky to get more than two and I don't think Mercurial can.) If you run with verbose or debug messages enabled, you will see several messages regarding the "bid merge" process. Bid merge is described (not very well, in my opinion) in https://www.mercurial-scm.org/wiki/BidMerge.
The message you saw indicates that the bid-merge algorithm was unsuccessful at choosing a "best ancestor" and Mercurial fell back on its "choose an ancestor at (apparent) random" method.
The lack of a "best LCA" arises from "criss cross merges", where you merge branch A into B and branch B into A. Without such merges there is always a single best LCA, if there is any LCA at all. This does not mean you must avoid such merges, but it does mean you should be aware that if you do make them, you may run into ambiguous merge-base issues.
Related
ZIO (https://zio.dev/) is a scala framework which has at its core the ZIO[R, E, A] datastructure and its site gives the following information for the three parameters:
ZIO
The ZIO[R, E, A] data type has three type parameters:
R - Environment Type. The effect requires an environment of type R. If this type parameter is Any, it means the effect has no
requirements, because you can run the effect with any value (for
example, the unit value ()).
E - Failure Type. The effect may fail with a value of type E. Some applications will use Throwable. If this type parameter is
Nothing, it means the effect cannot fail, because there are no
values of type Nothing.
A - Success Type. The effect may succeed with a value of type A. If this type parameter is Unit, it means the effect produces no
useful information, while if it is Nothing, it means the effect runs
forever (or until failure).
It's easy to get what A is: it's the value returned by the function in the nominal case, ie why we coded the function for.
R is so kind of dependency injection - an interesting topic, but we can just ignore it to use ZIO by alway setting it to Any (and there is actually a IO[E, A] = ZIO[Any, E, A] alias in the lib).
So, it remains the E type, which is for error (the famous error channel). I roughtly get that IO[E, A] is kind of Either[E, A], but deals with effect (which is great).
My question is: why should I use an error channel EVERYWHERE in my application, and how can I decide what should go in the error channel?
1/ Why effect management with an error channel?
As a developper, one of your hardest task is to decide what is an error and what is not in your application - or more preciselly, to discover failure modes: what the nominal path (ie the goal of that code), what is an expected error that can be dealt with by the application in some way later on, and what are unexpected errors that the application can't deal with. There is no definitive answer for that question, it depends of the application and context, and so it's you, the developper, who needs to decide.
But the hardest task is to build an application that keeps its promises (your promises, since you chose what is an error and what is the nominal path) and that is not surprising so that users, administrators, and dev - including the futur you in two weeks - know what the code do in most cases without having to guess and have agency to adapt to that behavior, including to respond to errors.
This is hard, and you need a systematic process to deals with all the possible cases without going made.
The error channel in IO bi-monad (and thus ZIO) helps you for that task: the IO monad helps you keep track of effects, which are the source of most errors, and the error channel makes explicit what are the possible error cases, and so other parts of the application have agency to deal with them if they can. You will be able to manage your effects in a pure, consistant, composable way with explicit failure modes.
Moreover, in the case of ZIO, you can easely import non-pure code like legacy java extremelly easily:
val pure = ZIO.effect(someJavaCodeThrowingException)
2/ How do I choose what is an error?
So, the error channel provide a way to encode answer to what if? question to futur dev working on that code. "What if database is down?" "there's a DatabaseConnectionError".
But all what if are not alike for YOUR use case, for CURRENT application level. "What if user is not found?" - ah, it may be a totally expected answer at the low, "repository" level (like a "find" that didn't find anything), or it can be an error at an other level (like when you are in the process of authenticating an user, it should really be there). On the first case, you will likely not use the error channel: it's the nominal path, sometimes you don't find things. And in the second case, you will likelly use the error channel (UserNotFoundError).
So as we said, errors in error channel are typically for what if question that you may want to deal with in the application, just not at that function level. The first example of DatabaseConnectionError may be catch higher in the app and lead to an user message like "please try again" and a notification email to sysadmin ("quick, get a look, something if wrong here"). The UserNotFoundError will likely be managed as an error message for the user in the login form, something like "bad login or password, try again or recover credentials with that process".
So these cases (nominal and expected errors) are the easy parts. But there are some what if questions that your application, whatever the level, has no clue how to answer. "What if I get a memory exception when I try to allocate that object?" I don't have any clue, and actually, even if I had a clue, that's out of the scope of the things that I want to deal with for that application. So these errors DON'T go in the error channel. We call them failure and we crash the application when they happens, because it's likely that the application is now in an unknow, dangerous, zombie state.
Again, that choice (nominal path/error channel/failure) is your choice: two applications can make different choices. For example, a one-time-data-processing-app-then-discard-it will likelly treat all non-nominal paths as failures. There is a dev to catch the case in realtime and decide if it's important (see: Shell, Python, and any scripting where that strategy is heavely used - ok, sometimes even when there is no dev to catch errors:). On the other end of the specter, Nasa dev put EVERYTHING in the error channel(+), even memory CORRUPTION. Because it is an expected error, so the application need to know how to deal with that and continue.
(+)NOTE: AFAIK they don't use zio (for now), but the decision process about what is an error is the same, even in C.
To go further, I (#fanf42) gave a talk at Scala.io conference. The talk, "Ssytematic error management in application", is available in French here. Yes, French, I know - but slides are available in English here! And you can ping me (see contact info near the end of slide deck).
So, here's the situation. I have 2 streams, "Development.Main" and "Development.A" (child of Development.Main). I will focus only on the "path" that one file took through my "versioning" steps that I executed.
The file starts out in Main.
I merge it down to A with no changes.
I delete it in Main.
When I go to merge the changes in Main down to A, I choose to "Keep Target", so that the file remains undeleted in A, because I want the file deleted in Main, but not in A.
But then the Perforce stream diagram tells me that I have files to copy from A to Main (see the green arrow). And when I go to do the Copy operation (from A to Main) it wants to copy the file back into Main, thereby regenerating it. But I want it to stay deleted. Note that, when I try to force a merge (instead of a copy) from A to Main, Perforce thinks that there is nothing to merge and it decides to respond with an error. See image #3 below
1 - Stream Diagram
2 - Revision Graph
3 - Trying to force the merge from A to Main
How do I solve this situation, so that I can delete the file in Main but not in A?
Conditions for the solution:
I want all green arrows to go away on the stream diagram.
From now on, I don't want this file to show up in the Copy (from A to Main) operation. (Because I don't want this file to show up in Main again. It's supposed to be deleted there.)
I don't want to change anything about the stream spec or workspace spec just for this specific file.
There are two ways to do this:
Option one (general solution):
Don't ever do the copy operation between these two streams. The merge/copy workflow is not compatible with the idea of "ignoring" changes, because as soon as you copy you force the two streams to be identical regardless of what has previously been ignored.
Fortunately, streams have a mergeany option that allows you to opt out of the merge/copy workflow, so you can instead merge/merge without having to use the -F (force) flag each time -- this was the standard Perforce workflow before streams existed. When you merge, previously "ignored" revisions will not be merged, nor will revisions that were themselves the product of an "ignore" in the reverse direction (i.e. your ignored delete will not re-propagate as an add if you're doing a merge).
The ability to "ignore" branch/delete operations in this way is described in more detail here (again, note that this only works with merge/integrate, not copy): https://web.archive.org/web/20141020052100/http://www.perforce.com:80/blog/110620/ignoring-branches-deletes
Option two (for entire files only):
Since this is an entire file that you don't want to propagate, rather than a specific revision, you can isolate it in Development.A's Paths. This will remove it from the integration view so that no changes made to that file will propagate (in either direction, regardless of whether you're merging or copying). From the point of view of the copy, this file is simply no longer part of your stream.
I am using py.test with selenium and applitools Eyes --- those latter parts don't matter, only the py.test part does. I am computing some session-level configuration of a test run using session-level fixtures, like so:
#pytest.fixture(scope='session')
def branch(request,timestamp):
branch = request.config.getoption('--branch')
if not branch and not request.config.getoption('--live'):
# auto-generate branch
branch = "auto " + timestamp
return branch
I would like to print the computed value as part of the test header---or any other way to get it to true stdout.
I first tried using capsys.disable() in the branch function above, but I got an error message that capsys is a function-level fixture so cannot be used by a session-level fixture. Fair enough.
Then I tried to copy the example for adding information the test report header:
def pytest_report_header(config,branch):
print branch
But it doesn't seem that branch is available as a fixture for pytest_report_header. I could call the branch() function directly, but that kind of defeats the purpose.
I have seen this question but I can't tell if it applies --- it is a bit over my head py.test-wise.
This seems like it ought to be a simple thing to do, but I'm stuck --- any ideas?
I haven't figured out an answer to the question I asked, but I have figured out a solution to my problem: since I am doing selenium testing, the entire output-capturing thing is irrelevant in my case, so I can turn it off entirely.
I just discovered the -s flag for py.test, which does just that.
Given a node id or matcher, is there a way to determine what state files will be pushed on a state.highstate - without actually running them? i.e. like a dry run.
I have a lot of templating going on in my state files and would like to see what would actually be affected before committing to a run.
You can see what states are being applied by top to a given set of servers with salt $MATCHER state.show_top.
You can do a dry run with salt $MATCHER state.highstate test=True (case sensitive). I don't entirely trust it; sometimes it claims something should get changed, but when I run a real highstate, it turns up clean. I have never had the opposite occur, thankfully.
I have a fairly good idea of what the Subject class does and when to use it, but I've just been looking through the language reference on msdn and see there are various other ISubject implementations such as:
AsyncSubject
BehaviorSubject
ReplaySubject
As the documentation is pretty thin on the ground, whats the point of each of these types and under what situations would you use them?
These subjects all share a common property - they take some (or all) of what gets posted to them via OnNext and record it and play it back to you - i.e. they take a Hot Observable and make it Cold. This means, that if you Subscribe to any of these more than once (i.e. Subscribe => Unsubscribe => Subscribe again), you'll see at least one of the same value again.
ReplaySubject: Every time you subscribe to the Subject, you get the entire history of what has been posted replayed back to you, as fast as possible (or a subset, like the last n items)
AsyncSubject: Always plays back the last item posted and completes, but only after the source has completed. This Subject is awesome for async functions, since you can write them without worrying about race conditions: even if someone Subscribes after the async method completes, they get the result.
BehaviorSubject: Kind of like ReplaySubject but with a buffer of one, so you always get the last thing that was posted. You also can provide an initial value. Always provides one item instantly on Subscribe.
In light of the latest version (v1.0.2856.0) and to keep this question up to date, there has been a new set of subject classes:
FastSubject, FastBehaviorSubject, FastAsyncSubject and FastReplaySubject
As per the release notes they
are much faster than regular subjects
but:
don’t decouple producer and consumer by an IScheduler
(effectively limiting them to
ImmediateScheduler);
don’t protect against stack overflow;
don’t synchronize input messages.
Fast subjects are used by Publish and
Prune operators if no scheduler is
specified.
In regards to AsyncSubject
This code:
var s = new AsyncSubject<int>();
s.OnNext(1);
s.Subscribe(Console.WriteLine);
s.OnNext(2);
s.OnNext(3);
s.OnCompleted();
prints a single value 3. And it prints same if subscription is moved to after completion. So it plays back not the first, but the last item, plays it after completion (until complete, it does not produce values), and it does not work like Subject before completion.
See this Prune discussion for more info (AsyncSubject is basically the same as Prune)
Paul's answer pretty much nails it. There's a few things worth adding, though:
AsyncSubject works as Paul says, but only after the source completes. Before that, it works like Subject (where "live" values are received by subscribers)
AsyncSubject has changed since I last ran tests against it. It no longer acts as a live subject before completion, but waits for completion before it emits a value. And, as Sergey mentions, it returns the last value, not the first (though I should have caught that as that's always been the case)
AsyncSubject is used by Prune, FromAsyncPattern, ToAsync and probably a few others
BehaviorSubject is used by overloads of Publish that accept an initial value
ReplaySubject is used by Replay
NOTE: All operator references above refer to the publishing set of operators as they were before they were replaced with generalised publish operators in rev 2838 (Christmas '10) as it has been mentioned that the original operators will be re-added