Closed tommix1987 closed 7 years ago
Answered myself - yes the script seems to sort out demotes properly ;)
Thanks for checking, I was waiting for @orao to answer. The underlying mechanism is to treat every transaction as if it might introduce a change to the streams that you are interested in and then check to see if any changes actually have been made. There are various optimizations that help to speed up the process but essentially any type of transaction will be processed.
If you find a problem or can suggest an improvement then please don't hesitate to contribute.
Thanks for your response. Yes it seems that the script went through demote operation without a problem. I've made few tweaks locally for my repo (but null checks here and there since the script failed few times with my repo). I will try to create PRs for those as soon as I can. Also what really helped me was disabling support for timelocks, this was somehow breaking my migration. I don't need timelocks support anyway so was the right few fix for me. I will try to raise an issue to make this flag configurable, so that one can decide whether to use this feature of the script or not. FYI I've been running it on Accurev 6.2.2, Windows 10, and Python 3.4.3 all more-less fine until now.
Awesome, glad this was a help to you.
The script has two stages and the first doesn't care about transaction types but the later merging stage does, to a degree. The merging ignores some transactions, special handles the mkstream
and chstream
transactions, and for all other transactions it only cares whether the stream is a workspace
or a normal
stream (note: snapshot
streams are handled elsewhere).
Hence, it shouldn't matter so much if new transactions are introduced. You can add to the list of ignored transactions any new transactions that are introduced, which can be safely ignored, and confuse the script. In the worst case demote
could have been ignored which means it would have simply been "squashed" (in Git terminology) into the subsequent transaction.
However, as you noted, the script should correctly handle this case anyway.
P.S. The reason the first stage doesn't care about transaction types is because it is based on the output of the accurev hist
and accurev diff
commands with some special handling of chstream
and mkstream
transactions. Hence, if any new transaction types are added it should handle it fine.
Hi is the script compatible with Accurev's Demote functionality that was introduced in 6.2?