[Top][All Lists]

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

Re: Patch for making CommitID configurable

From: Peter Backes
Subject: Re: Patch for making CommitID configurable
Date: Wed, 27 Apr 2005 22:46:16 +0200


On 27 Apr 2005 at 12:48, Mark D. Baushke wrote:

> > (long)time(NULL), getpid(): not portable.
> That one requires supporting documentation.
> Which platforms do not provide them? CVSNT and CVS both use them
> extensively across all of our supported platforms.

I can only say that Standard C doesn't specify any type for time_t, 
it is entirely opaque and can be implemented as a struct.  I think I 
have read some systems choose double.  getpid() is POSIX.

But it's not about CVS, it's about the file format.  A portable file 
format should not contain any information which cannot be 
created/processed in a portable way.  

> > Why not simply keep a counter 
> This would create a hot-spot for contention of all cvs commits for the
> repository in very large and very busy repositories this would be a
> nightmare.

Locking one file as small as about 6 bytes, reading, writing and 
unlocking it?  I guess it wouldn't be a bottleneck, but it can only 
be told by measuring.

> If you want a 'better' global_session_id, then perhaps doing a SHA256
> hash of all of the files being committed in this session would be more
> unique... of course, that is problematic for other reasons.

Doesn't work.  If you undo a change and commit the result, you'd get 
duplicate commit IDs.  It would also be extremely slow.

Also, compare-by-hash is not an option for a general SCM, because if 
researchers working on hash collisions broke some hash function and 
have their related files under revision control, effects can be 
disasterous.  I already noticed such effects working with common file 
distribution tools (which use compare-by-hash) on files in my crypto 
folder, some of which are recently discovered hash collisions.

> > I guess -k and mergepoint are only being written on user request.  
> It happens when users do a 'cvs update -j branch-tag' command. See
> http://www.cvsnt.org/wiki/MergePoint for details. So, it is not really
> very explicit on the part of the user in some sense.

Then if it should be implemented in CVS, IMO it should be done a way 
that makes it's creation more explicit.

Peter 'Rattacresh' Backes, rtc@helen.PLASMA.Xg8.DE

reply via email to

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