[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Commit ID Enhancement
From: |
Derek Robert Price |
Subject: |
Re: Commit ID Enhancement |
Date: |
Mon, 24 May 2004 20:59:34 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Todd Denniston 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.
>
>From my perspective, only a minor improvement, as it only builds into cvs
>something that I can do as frequently or seldom as I (as the cm person on
>several projects) chose.
True, but automation can remove some of the grunt work, though I don't
think this enhancement will cause you to want to stop tagging
releases. :)
>>If a unique commit id tag were applied to each revision as it is
>>committed (unique across the repository and the same for each file in
>>a commit), this might be a useful step towards the merge/change set
>>tracking some people have proposed.
>>
>>Such a special tag could be accessed to back out a single commit,
>>implying something like `up -j <cid> -j <<cid> -1>' when used alone to
>>back out a single, complete, "change".
>>
>>I would think that either a new namespace and new options // to or
>>syntax involving -r & -j would be in order or a namespace outside the
>>current tag namespace, perhaps using names that start with a character
>>currently prohibited in tags. I definately prefer the latter but I
>>have not examined all the implications of that change.
>>
>How about instead of reserving a namespace _from_ all users of CVS,
allow them
>to specify in a file (in $CVSROOT/CVSROOT/????) the pattern that they
want
>used.
>their header and global number:
>"boneheadedCommitNumber%n"
I'm not talking about reserving a new namespace - I am proposing
opening up some namespace that is already restriced for these commit
id tags, which have some special property.
>also with the current implementation of tags the tag would need
applied across
>the whole repository, because if they wanted to checkout against the
tag they
>only get those tags that were tagged with that tag... not a problem
with diffs
>though. BTW I am not suggesting changing the current implementation of
>checkout against tags, I use that effect when I want only a
particular set of
>files checked out for tests but want all available for development.
No. I was envisioning that they would only be useful to back out a
discrete "commit", in which case the effect would be like
cvs -q up -j<cid> -j<rev b4 cid>
Which would back out the discrete commit and have no discernable
effect on files without the tag.
>>Just an idea in case anybody has any spare time on their hands.
>
>Not enough spare time to do anything other than grump. :}
You and everybody else. :)
Derek
- --
*8^)
Email: derek@ximbiot.com
Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAspp1LD1OTBfyMaQRAsN3AJ4wAs2+UfJn3ZsaU/U0Iy/xJ6J4DQCaAmd5
ee4CD/SzqQartyPLr/xmRrQ=
=uhAZ
-----END PGP SIGNATURE-----