monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Proposal for human readable revision IDs


From: Thomas Haas
Subject: Re: [Monotone-devel] Re: Proposal for human readable revision IDs
Date: Wed, 07 Sep 2005 13:37:51 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Bruce Stephens wrote:
> Thomas Haas <address@hidden> writes:
> 
> [...]
> 
> 
>>Due to the distributed nature and local scope of incremental
>>revision numbers in monotone, the semantic would be ordering of
>>commit, sync, and pull operations in time. I believe this semantic
>>would also be intuitive and very easy to understand.
> 
> 
> That would work provided all the relevant machines had sufficiently
> synchronised clocks.  And provided no two revisions occurred during
> the same second (or whatever time interval you chose).  
> 
> Neither assumption fills me with confidence; probably more relevantly,
> monotone deliberatly avoids making similar assumptions about time, so
> I doubt the developers would go for this.

There is no dependencies on a time source (Clock) at all. If you want,
the incremental revision numbers form a virtual clock (if you are
familiar with that concept). If I commit my stuff and then sync with
you, my revisions are lower (before) than your revisions (after)
independently on whether you committed your stuff before I did (relative
to UTC, let's say).

The revisions get an incremental version number assigned as the
revisions come into existence be it via commit, sync, pull, or reading
packets.

This ordering might be intuitive to the user, because, I might remember
to have committed my stuff (rev 255) and then pulled your stuff (revs
256 through 287 -- you were busy) and then, I committed again my stuff
(revision 288). It does not matter, whether you committed your stuff to
your repository. Also, if a third person is involved, the revisions
might have different orders within the different repositories.


Regards
- tom






reply via email to

[Prev in Thread] Current Thread [Next in Thread]