info-cvs
[Top][All Lists]
Advanced

[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: address@hidden

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-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]