Hi, Kristian! On Apr 28, Kristian Nielsen wrote:
Sergei Golubchik <serg@mariadb.org> writes:
note, that two *different* revisions got the same revno! And the changes from the first revision are completely and totally lost, there is no way to retrieve from from anywhere.
Indeed.
But note that in main trees (5.1, 5.2, 5.3, 5.5, and 10.0), this cannot occur, since we have set the append_revision_only option (or "append_revisions_only", can't remember). This prevents a revision number from changing, once pushed.
So in main trees, the revision number _should_ in fact be unique.
Yes. I omitted that detail, because I hope that we can find a solution that works for all trees without checks that only work for main trees. But, of course, as the last resort we can rely on append_revisions_only.
Revision-id is the only unique identifier for a revision, unfortunately, it's not logged in these tables. I believe we'll change buildbot so that revid would be logged in the future. But so far it wasn't needed, and this is one of the defects in the data.
I actually wanted to log it when I wrote the code. The problem is that the revision-id is not available to buildbot when the change is received from Launchpad. I even asked the bzr/launchpad developers to provide the revid: so it could be logged. The answer I got was that it is a deliberate feature to hide the revision id :-(
https://bugs.launchpad.net/launchpad/+bug/419057
So I don't think we will get revid in Buildbot. Of course, if we go to git, we will not have this problem anymore, as it always uses a consistent, stable revision identifier.
Oh, I see, thanks. Git - yes, that's not an issue. Bzr - perhaps we could figure out something regardless. May be get the revid on the tarbake builder - it needs the tree anyway. Or use fake revids. Or something. It is not a showstopper for this project, we can think about it later, when we finish the research part and get to the integration. Regards, Sergei