Try and infer the source stream when it is unavailable

[orao]

For depots on old versions of Accurev or depots that have undergone an update/upgrade from old versions of Accurev there will be transactions for which the fromStreamName and fromStreamNumber attributes of the <transaction /> element in the XML output of the accurev hist command is missing. This means that we can't perform a merge for a promote in these cases.

It should be possible to try and infer, in a naive way, if the transaction came from one of the child streams of the stream on which the promote occurred.

If we find a child stream that was different from this stream (its basis stream) at the previous transaction (whatever it may be) and that at this transaction it becomes the same then it is extremely likely that the promote came from that stream.

Even if we are processing only a subset of streams this naive algorithm should work pretty well, even in the cases where the promote came via an untracked intermediate stream.

[orao]

This would be solved by solving issue #51.

[ghost]

These are the assumptions which should apply to the inferred source stream:

1. The source stream was not changed by this transaction.
   1.1. The source stream therefore cannot be timelocked.
2. The destination stream was changed by this transaction.
3. The destination stream's contents is exactly the same as the source stream's contents at this transaction.

If these assumptions hold for a child stream and a basis stream where the child stream is assumed to be the source stream and the basis stream is assumed to be the destination stream then we can find the most likely source stream.

If any of these are untrue we reduce the likelihood and should probably not continue.

[fatfreddie]

Good insight about source stream not changing but not sure the conclusion is valid. I'm pretty sure it is possible to promote from a time-locked child stream into a parent stream.

[ghost]

That is correct and it won't be handled by the algorithm, which leaves us in the same position w.r.t. time locked streams but improves the situation for non-timelocked streams.

[ghost]

Without recreating and tracking stream default sets there is little chance of having a perfect solution.

[fatfreddie]

Now there's a thought ... but no that's way too expensive for the benefit.

[ghost]

Though this is a limited use case it is one of the more common ones, hence this solution, provided it is implemented correctly should be useful.