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 3:21, Mark D. Baushke wrote:
> 
> > It may be worth noting that CVSNT has had this feature for a long time
> > and moving to adopt it satisfies a minor goal of trying to reduce the
> > separation and entropy between the major CVSNT fork of CVS and the CVS
> > that cvshome offers.
> 
> I agree that a commit ID might be a handy feature, but the way CVSNT 
> did it was merely a quick and dirty hack IMO.  It relies on the 
> concept of seconds since epoch, which is not portable.  Further the 
> commit ID can only be assumed to be unique for a certain repository, 
> so the whole thing cannot be used if somebody wants to build a 
> distributed SCM on top of CVS.

The currently generated global_session_id is indeed ((2*sizeof(int)) + 12)
bytes in size and on most platforms that will be 16 bytes. However, the
CVSNT specification says that it may be

    global_session_id = Xasprintf ("%x%08lx%04x", (int)getpid(),
                                  (long)time (NULL), rand()&0xFFFF);

Concerning the CVSNT sources...
One 'bug' is that src/RepositoryDatabase.cpp uses
'commitid CHAR(16) not null,' and the CVSNT sources use

  src/cvs.h:#define GLOBAL_SESSION_ID_LENGTH 64
  src/cvs.h:extern char global_session_id[GLOBAL_SESSION_ID_LENGTH];
  doc/cvs.dbk:
                <primary>COMMITID, internal variable</primary>
              </indexterm>Unique Session ID of cvsnt process. This is a random
            string of printable characters that may be up to 256 characters
  src/main.cpp
static void make_session_id()
{
        
sprintf(global_session_id,"%x%08lx%04x",(int)getpid(),(long)time(NULL),rand()&0xFFFF);
}

which means that it is possible for CVSNT to handle 63 bytes in the
global_session_id plus the '\0' byte or for display purposes they
document a 256 character limit.

Of course, at present both CVS and CVSNT are only using [a-fA-F0-9] for
the characters in the string although CVS allows for [a-zA-Z0-9] in our
sanity.sh testing and CVS does not used a fixed buffer length so we
could easilty increase the size of the formulation if there is a need.

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.

If there are any other suggestions for how the global_session_id should
be modified, I would like to see it discussed.

> I stick to my opinion that currently loginfo provides a much better 
> way to achieve what Jim sees CommitID useful for.

Are there any other folks that wish to chime in on this discussion?

> > I honestly do not think this feature is the problem you seem to believe.
> 
> Even if it isn't, I don't see why it shouldn't be possible to apply 
> my patch to let the user decide what he wants.  What is currently 
> being done is that users are forced to have CommitIDs even if they 
> don't want them (for whatever reason).  This cannot be right.

Hmmm... cvs 1.12.x is where we are doing new features that we consider
to be reasonable as the future direction of CVS. It is not yet the
stable version. If possible, when this version is blessed as STABLE to
replace the cvs 1.11.x series, we would rather have a standard version
that interoperates well with all other clients and servers.

If other people believe strongly that this feature needs to be a
compile-time or pre-repository config option, we can consider it and
bring it to a vote among the developers based on user input.

For example, I am waiting to hear what Greg A. Woods has to say on this
subject. He has been fairly vocal in the past about retaining the older
RCS ,v format without extension.

> > If you can provide more consumers of the ,v files that have problems
> > using the addition to the format, it would be good to have that list.
> 
> Besides rcs, I only remember cvsup as a program that might access the 
> files in a CVS directory directly.  However, I don't know if it has 
> any problems with the addition to the format, as I don't use it.

Yes. I know about CVSup and CVSupd. I believe that it handles
"newphrases" in the tree section of the delta without any problems. See
RCSDelta.m3 IterateTextPhrases and IterateTreePhrases. It just walks
them in order and preserves them.

So, to be clear, the following are potential consumers of additions:

  RCS - the format allows for newphrases and RCS has a -q switch to
        inhibit complaints about it not understanding how to use the
        newphrase it does not recognize.

  CVS - cvs 1.12.x has introduced "commitid" into the delta structure

  CVSNT - The original home of the "commitid" allowed for a 64byte
          buffer on generation and documents in cvs.dbk that it may be
          up to 256 characters long.

  CVSup - seems to handle RCS extensions without caring what they do.

There are a number of tools and utilities that use RCS which may have
problems:

  ViewCVS
  CVSWeb
  SmartCVS
  TortoiseCVS

but I suspect that all of them have already run across the CVSNT
commitid and are handling it correctly.

CVS has added stuff to the RCS format in the past, even though those
options are usually disabled: "permissions" and "hardlinks".

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.

At present CVS does not support UNICODE, but I would not rule out the
possibility that it may do so in the future.

Are there any other comments or questions on this topic?

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

iD8DBQFCb9Ue3x41pRYZE/gRAm7UAKDOPPFdsye3nJkJPenr2uUbumFjjgCgql2n
J2coVdXzyIScblsi+pHUptA=
=/c1V
-----END PGP SIGNATURE-----