Hello, On 27 Apr 2005 at 18:11, Derek Price wrote:
> This information doesn't need to be processed in any non-opaque way > once created, but uniqueness is an argument. Once created, it can be > passed, basically, as a tag to CVS, at which point only uniqueness > matters. not where the unique value came from. In real world conditions, uniqueness of the current solution is questionable, as often computer clocks are wrong and are adjusted on the fly by several minutes, for example with ntpdate. This is not recommended, but it happens. Also repositories are sometimes copied to a different machine with a differing clock. If a repository is under heavy load (several commits per second) under situations where the clock might be changed into the past, PID and randomness are the only protection against collisions. Why not measure speed of an rcsfreeze-like solution where commit IDs are guaranteed to be unique? I'm interested if there's really a bottleneck. > I really dislike the idea of making the user request it be enabled, > unless there is a darn good reason. I do not yet consider a few > warning messages from RCS a darn good reason. I see. If any suasion fails, the only solution is another fork of CVS, this seems inavoidable to me. The time spent discussing is probably better spent programming. -- Peter 'Rattacresh' Backes, [EMAIL PROTECTED] _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs