Re: Commit ID Enhancement

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

Derek Robert Price <[email protected]> writes:

> Jim.Hyslop wrote:
> 
> >Derek Robert Price wrote:
> >
> >>It occurred to me that a "Commit ID" implemented as a tag might make a
> >>useful addition to the CVS feature-set.
> >
> >
> >CVSNT has a unique commit ID, but it doesn't look like it's
> implemented as a
> >tag. The sample log at http://www.cvsnt.org/wiki/MergePoint shows, in
> part:
> >
> >----------------------------
> >revision 1.8
> >date: 2003/11/06 21:53:13;  author: gstarret;  state: Exp;  lines: +0 -0;
> >kopt:
> > kv;  commitid: 257f3faac2c9c824;  mergepoint: 1.6.2.1;
> >changed for some reason
> >----------------------------
> >
> >Does this come close to what you had in mind?
> 
> 
> I suppose. As long as the commitid would be given special
> properties there may not be any good reason to treat it
> exactly like a tag otherwise, but there would be some
> overlap.

Hmmm... I thought the best part of the commitid feature was
that it set an environment variable COMMITID that could be
used to better allow commitinfo/verifymsg/loginfo to share
information between themselves...

I suspect that the commitid -- a unique per-commit value
which is based on the pid, time and a rand() sixteen bit
value in hex format may also be used where a symbolic tag
exists (e.g., cvs diff -u -r@77653f84ac702eeb) to address
only those files handled by the 77653f84ac702eeb cvs commit.

> What sort of mergepoint processing does CVSNT do?  The link you sent
> appears to be down just now.

Well, here is the link I found...

http://www.cvsnt.org/wiki/MergePoint?action=highlight&value=mergepoint

<<
1. What is a mergepoint, and how does one use it?

Mergepoints help cvsnt find the common ancestor when trying
to diff a file, which greatly reduces the effort required to
merge in branches. It is automatically saved by cvsnt when
you merge changes from one branch to another. Just make sure
you commit after merging (before performing any other
merges) and cvsnt will save the mergepoint field with the
update.

Note that mergepoints are specific to cvsnt, and require
that cvsnt is running on both client and server. "Regular"
cvs does not support mergepoints.

When I merge back and forth from dev branch to HEAD, it is a
very simple operation--I just specify the branch to merge
from, and cvsnt takes care of the rest. If you read about
merging in the regular cvs docs, it looks like a big effort
to tag before, merge, commit, retag... lots of tagging and
remembering those tag names.

With cvsnt, merging is done simply by using:     

	cvs update -j branch-tag 

Then you can correct any conflicts, test your integration,
and commit without worrying about a lot of tagging
operations.

You can see the mergepoint records in the output of the log
command (look at rev 1.8, the last field before the
comment):

C:\temp\junk\test>cvs log test.c

RCS file: /home/cvsroot/test/test.c,v
Working file: test.c
head: 1.8
branch:
locks: strict
access list:
symbolic names:
        grs-test1: 1.6.0.2
        R2: 1.3
        R1-Fix: 1.1.0.2
        R1: 1.1
keyword substitution: kv
total revisions: 12;    selected revisions: 12
description:
- ----------------------------
revision 1.8
date: 2003/11/06 21:53:13;  author: gstarret;  state: Exp;  lines: +0 -0;  kopt:
 kv;  commitid: 257f3faac2c9c824;  mergepoint: 1.6.2.1;
changed for some reason
- ----------------------------

That mergepoint is in the record from my commit after I did the merge. 
>>

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

iD8DBQFAtDoIDsmuPPFOO2cRAlkGAJ9McLBS+Msj2nyfLKXpT1vtbaruFgCfQY+w
uIVLr66r0Gp9xCuwamxGgCc=
=beuU
-----END PGP SIGNATURE-----