Bitkeeper changeset numbering glitch in 2_4_devel tree

Bitkeeper changeset numbering glitch in 2_4_devel tree

[Eugene Surovegin]

Hi all!

I noticed strange changeset renumbering anomaly in devel_2_4 bitkeeper tree.
It happend on July 23d, after dan@dp500.netx4.com pushed his changes
(changeset 1.1091).

Bitkeeper for some reason considers now his branch is a main line of the
development and has renumbered everything happened between Jun 7th  and Jul
23rd to be the side branch.

It looks to me that there is no way to identify any changeset in a robust way.

What today shows up as changeset 1.1155 may in future become something like
1.1088.1.30. I'm sure that Bitkeeper uses other way of identification
internally but it's not user accessible.
It's a little disturbing.

May be I'm just missing something :(.


  Eugene Surovegin <mailto:ebs@innocent.com>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bitkeeper changeset numbering glitch in 2_4_devel tree

[Larry McVoy]

> What today shows up as changeset 1.1155 may in future become something like
> 1.1088.1.30. I'm sure that Bitkeeper uses other way of identification
> internally but it's not user accessible.

The internal names are called keys or inodes and you get at them with

	bk prs -hr<whatever> -nd:KEY: <filename>

In general, anywhere you can use a revision, you may use a key instead.
Nt in BK/web yet though.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/