On Thu, 05 May 2011 01:32:42 +0200, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
Honestly, I don't know what the issue is. I am trying to get my head around what goes wrong when there is no centralized revision numbering. Like the example I gave earlier showed, linear revision numbers are just that: linear revision numbers. In the distributed world there is no requirement that 40439 came before 43943, it only means that 43943 was pushed later to haiku-central (the new central repository) than 40439. Whatever that means.It means that running a 43943 (derived) version contains all the changes up to that number. No, there's nothing wrong with not having a linear revision number, but it makes things significantly less convenient. When I read "bug fixed in 40439" and I run 43943 then I known my version includes the bug fix, while it doesn't the other way around (unless I pulled the fix from some other repository before it went to haiku-central). When I read "bug fixed in 8d5dc105106fb0bf1fe83494a184ca740278745f" and my Haiku is 037ea432d72fa9246f0e6b59aba861055d2345bd, then that tells me exactly nothing without looking it up. Even the "describe" stuff is only marginally helpful: Does "r1a2-192-b969c5a" include bug fix "r1a2-190-892f219"? If the latter is from the haiku-central and the former doesn't have any local changes then yes, otherwise maybe or maybe not.
Official builds can be tagged with an extra pre/suffix attached to the describe id to take care of that. As long as you can identify official builds and can order them, that's already pretty useful. With the descriptors, you get some additional information (the tag) that helps to put things into perspective. I would give up trying to pack much more information in a short descriptor, as we'd be running into the laws of data compression :)
How would you handle nightly builds of experimental branches (not unthinkable) using sequential revision numbers?