-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Backes <[EMAIL PROTECTED]> 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-----
_______________________________________________
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
