{"thread":{"id":"5960","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","startedAt":"2006-10-20T02:09:49Z","lastAt":"2006-10-20T05:38:42Z","messageCount":2,"participants":["Horst H. von Brand","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29283","messageId":"200610200209.k9K29ncC006935@laptop13.inf.utfsm.cl","threadId":"5960","inReplyTo":"bulb@ucw.cz","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-20T02:09:49Z","receivedAt":"2006-10-20T02:09:49Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Jan Hudec wrote:\n\n[...]\n\n> Reading this thread I came to think, that the revnos should be assigned\n> to _all_ revisions _available_, in order of when they entered the\n> repository (there are some possible variations I will mention below)\n> \n> - Such revnos would be purely local, but:\n> - Current revnos are not guaranteed to be the same in different\n> branches either.\n> - They could be done so that mirror has the same revnos as the\n> master.\n\nThen they are almost useless (except for people working alone). You need to\nbe able to talk about a particular commit with others working independently.\n\n> - They would be easier to use than the dotted ones. What (at least as\n> far as I understand) makes revnos easier to use than revids is, that\n> you can remember few of them for short time while composing some\n> operation. Ie. look up 2 or 3 revisions in the log and than do some\n> command on them. And a 4 to 5-digit number like 10532 is easier to\n> remember than something like 3250.2.45.86.\n\nProbably. In git you can (mostly) get away with partial SHA-1's, BTW.\n\n> - Their ordering would be an (arbitrary) superset of the partial\n> ordering by descendance, ie. if revision A is ancestor of B, it would\n> always have lower revno.\n> - The intuition that lower revno means older revision would be always\n> valid for related revisions and approximately valid for unrelated\n> ones.\n> - They would be *localy stable*. That is once assigned the revno would\n> always mean the same revision in given branch (as determined by\n> location, not tip).\n\nTip-relative is extremely useful: I wouldn't normally remember the current\nrevision, but I'll probably often be talking about \"the change before this\none\" and so on.\n\n> - This is more than the current scheme can give, since now pull can\n> renumber revisions.\n\nUrgh. Get an update, and all your bearings change?\n\n> - They wouldn't make any branch special, so the objections Linus raised\n> does not apply.\n\nBut the original branch /is/ special?\n\n> - They would be the same as subversion and svk, and IIRC mercurial as\n> well, use, so:\n> - They would already be familiar to users comming from those systems.\n> - They are known to be useful that way. In fact for svk it's the only\n> way to refer to revisions and seem to work satisfactorily (though\n> note that svk is not really suitable to ad-hoc topologies).\n\nSVN is /centralized/, there it does make sense talking about (the one and\nonly) history. In a distributed system, potentially each has a different\nhistory, and they are intertwined.\n\nNot at all useful.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"29293","messageId":"20061020053842.GA28219@artax.karlin.mff.cuni.cz","threadId":"5960","inReplyTo":"200610200209.k9K29ncC006935@laptop13.inf.utfsm.cl","subject":"Re: Alternate revno proposal (Was: Re: VCS comparison table)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2006-10-20T05:38:42Z","receivedAt":"2006-10-20T05:38:42Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Oct 19, 2006 at 11:09:49PM -0300, Horst H. von Brand wrote:\n> Jan Hudec wrote:\n> \n> [...]\n> \n> > Reading this thread I came to think, that the revnos should be assigned\n> > to _all_ revisions _available_, in order of when they entered the\n> > repository (there are some possible variations I will mention below)\n> > \n> > - Such revnos would be purely local, but:\n> > - Current revnos are not guaranteed to be the same in different\n> > branches either.\n> > - They could be done so that mirror has the same revnos as the\n> > master.\n> \n> Then they are almost useless (except for people working alone). You need to\n> be able to talk about a particular commit with others working independently.\n\nAs they currently are you can't either. Because currently it is\nguaranteed that the revnos will be the same in two branches with the\nsame current revision. But when the current revisions differ, the\nnumbers may as well.\n\nMoreover currently they can change for the same branch over time, while\nwith the alternate proposal they would not, so you could reliably say\nrevision 567 on foo.\n\n> > - They would be easier to use than the dotted ones. What (at least as\n> > far as I understand) makes revnos easier to use than revids is, that\n> > you can remember few of them for short time while composing some\n> > operation. Ie. look up 2 or 3 revisions in the log and than do some\n> > command on them. And a 4 to 5-digit number like 10532 is easier to\n> > remember than something like 3250.2.45.86.\n> \n> Probably. In git you can (mostly) get away with partial SHA-1's, BTW.\n\n1) Partial sha-1 is still longer (starts being useful at 6 digits,\n usually you need 8)\n2) Decimal numbers are easier to remember than hexadecimal ones.\n3) The hashes are not oredered.\n\n> > - Their ordering would be an (arbitrary) superset of the partial\n> > ordering by descendance, ie. if revision A is ancestor of B, it would\n> > always have lower revno.\n> > - The intuition that lower revno means older revision would be always\n> > valid for related revisions and approximately valid for unrelated\n> > ones.\n> > - They would be *localy stable*. That is once assigned the revno would\n> > always mean the same revision in given branch (as determined by\n> > location, not tip).\n> \n> Tip-relative is extremely useful: I wouldn't normally remember the current\n> revision, but I'll probably often be talking about \"the change before this\n> one\" and so on.\n\nThat's however separate issue. Negative numbers are tip-relative and\nthere are various prefixes in bzr (like before:, ancestor: etc.) for\nrelative revision addressing.\n\n> > - This is more than the current scheme can give, since now pull can\n> > renumber revisions.\n> \n> Urgh. Get an update, and all your bearings change?\n\nCurrently yes. Currently pull changes the branch to be a mirror of the\npulled-from branch, including the way they are numbered.\n\n> > - They wouldn't make any branch special, so the objections Linus raised\n> > does not apply.\n> \n> But the original branch /is/ special?\n\nSome branches are usually special, but which they are may not\nnecessarily coincide with the left-parent lineage.\n\n> > - They would be the same as subversion and svk, and IIRC mercurial as\n> > well, use, so:\n> > - They would already be familiar to users comming from those systems.\n> > - They are known to be useful that way. In fact for svk it's the only\n> > way to refer to revisions and seem to work satisfactorily (though\n> > note that svk is not really suitable to ad-hoc topologies).\n> \n> SVN is /centralized/, there it does make sense talking about (the one and\n> only) history. In a distributed system, potentially each has a different\n\nDid you notice that I also said svk and mercurial? They both *ARE*\ndistributed (well, svk has it's limitations, but mercurial really very\nsimilar to git).\n\n> history, and they are intertwined.\n> \n> Not at all useful.\n\nThere are no global persistent revision numbers in a distributed system.\nThere can't be. But numbers with limited scope can still be really\nuseful. The question is what that scope should be.\n\n--------------------------------------------------------------------------------\n \t\t\t\t- Jan Hudec `Bulb' \n"}]}