Hello, 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, [EMAIL PROTECTED] _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
