Re: Patch for making CommitID configurable

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Backes <rtc@helen.PLASMA.Xg8.DE> writes:

> On 27 Apr 2005 at 11:08, Mark D. Baushke wrote:
> 
> >     global_session_id = Xasprintf ("%x%08lx%04x", (int)getpid(),
> >                                   (long)time (NULL), rand()&0xFFFF);
> 
> (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 will grant that time() may eventually (in 2036) need to be revisited
when the UNIX epoch wraps. I would support 64bit time if there were an
easy way to specify it. On some sytems, truncating getpid() to an int
may be less useful if sizeof(pid_t) is larger than sizeof(int). If you
know of any such systems, we could consider going to a larger type for
the Xasprintf() call.

> rand()&0xFFFF: makes commit IDs probabilistic, not unique.

True enough.

> 
> Why not simply keep a counter in a file which is being increased on 
> each commit and used as the commit ID?  This avoids the probabilistic 
> aspect and is entirely portable.  It was also the solution used for 
> rcsfreeze.  The location could be a config file option.

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.

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.

> > We are restricting the use of a '.' in the commitid, but we could
> > probably relax the encoding to allow a '%' sign and use a %2e escape
> > if you wanted to add in a FQDN for the hostname.
> 
> What is the reason for '.' being disallowed?

See the discussion on being able to use a commitid in a CVS tag in the
archives.

> > CVS has added stuff to the RCS format in the past, even though those
> > options are usually disabled: "permissions" and "hardlinks".
> 
> I would love to see any new feature adding to the RCS file format 
> being handled in exactly the same way.

The same way as your optional CVSROOT/config addition with it disabled
by default?

> > CVSNT has added "commitid" and "mergepoint" newphrases. It is entirely
> > possible that CVS could add support for a "mergepoint" newphrase in some
> > future release.
> 
> > CVSNT has also extended the -k flags to allow for UTF-8 characters.
> 
> I guess -k and mergepoint are only being written on user request.  
> (for example if he sets the new keyword or if he requests a 
> mergepoint to be written explicitely.)  This is entirely okay.  The 
> difference is that commitid is being written on each commit, while it 
> was not like that in the past, and currently in a way that does not 
> allow the user to prevent that.

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.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCb+x53x41pRYZE/gRAsscAJ94JZEx8WeLzfhh5Gnib51xFHcqggCggnwh
+7sEjFcPwO5tigU8ASEjZWY=
=gnOD
-----END PGP SIGNATURE-----