Re: BitBucket: GPL-ed KitBeeper clone

[Petr Baudis <pasky@ucw.cz>]

Dear diary, on Sat, Mar 15, 2003 at 10:32:46PM CET, I got a letter,
where Petr Baudis <pasky@ucw.cz> told me, that...
..snip..
> Changeset unique id should probably include author of that changeset and time
> (with seconds precision) of commiting such a changeset to the [original]
> repository [of the changeset]. However some insane scripts could make, checkin
> and commit several changesets in line fast enough or so, thus you want
> something else in the id as well, which could further differentiate commitins
> happenning at same time. Checksum of the changeset changes (in some suitable
> form) would do. Now, if you want to annoy Larry, separate the fields by '|'s
> and you could get something familiar.
..snip..

Okay, you will also need to define some project (let's define project as a
group of files with a history, where the instances of a project are called
"repositories" and are nodes of a DAG with common root, which we will call the
initial repository) unique id and include it in the changeset id. I think the
best for a project unique id would be some checksum (so that it isn't too
long..?) of the initial repository owner (project founder), project name (such
as 'linux' or 'foobar' or "this isn't going to be unique, who cares") and some
roughly random number (be it a timestamp, /dev/urandom output snippet or
metheorogical situation snapshot).

We could maybe raise the precision for timestamp of changeset ids instead of
having the checksum there, is it really neccessary? I fear of changeset id
being too annoyingly long and complicated. And yes I'm looking at BK heavily
regarding these concepts --- they seem to get these concepts fairly right so
why not.

Kind regards,

-- 
 
				Petr "Pasky" Baudis
.
The pure and simple truth is rarely pure and never simple.
		-- Oscar Wilde
.
Stuff: http://pasky.ji.cz/