Andreas Ericsson wrote:
> Aaron Bentley wrote:
>> Well, there's distributed, and then there's *DISTRIBUTED*. We don't
>> quasi-randomly merge each others' branches. We have a star topology
>> around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.
>>
>
> So in essence, the revnos work wonderfully so long as there is a central
> server to make them immutable?
>
> Doesn't this mean that one of your key features doesn't actually work in
> a completely distributed setup (i.e., each dev has his own repo, there
> is no mother-ship, everyone pulls from each other)?
>
> I can see the six-line hook that lays the groundwork for this in git
> before me right now. I'll happily refuse to write it down anywhere. I
> get the feeling that sha's are easier to handle in the long run, while
> revno's might be good to use in development work. In git, we have
> <branch/tag/"committish">~<number> syntax for this.
>
> In my experience, finding the revision sha of an old bug is what takes
> time. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly
> now, do you actually remember the revno for a bug that you stopped
> working on three weeks ago, or do you have to go look it up? If someone
> wants to notify you about the revision a bug was introduced, do they not
> communicate the revno to you by email/irc/somesuch?
Revnos were supposed to be superior to using sha1 (or shortened sha1)
as commit identifiers because of two key features:
1. They were simplier than sha1, therefore easier to use
2. Given two revisions related by lineage (i.e. one is ancestor of
the other) you can from a glance know which revision was earlier
But the details invalidated 1.: for complicated history, for a large
project, with many contributors and nonlinear development we have
www.repository.com:127.2.31.57 vs 988859a (7 chars shortcut of sha1)
to have immutable revno. And we have to use _immutable_ (up to few
years) revison identifiers, unless we want our "simple ids" scheme
to make a mess...
And I'm not sure if 2. is true, if even for revisions with direct
lineage we don't have to compare 127.15.2.16 with 210.2.20.3 for
example. Having generation number would solve 2.; as of now git
check for fast-forward case by checking if merge-base of two
revisions is one of the revisions.
--
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html