Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
I found the following reply from Tony in the daily digest, for some reason it's not appearing in my news client so I can't reply to it directly. > It wouldn't make sense - tags usually refer to whole trees of files, and commits only to things that > have changed. You could write a script that did one after the other... normally though you tag later > - after testing has determined that the branch is ready for promotion. > Tony My response is why doesn't it make sense? IMO it makes perfect sense, here are a couple of senarios: If a developer knows that a set of files he's commiting is all related to one feature or fix or just wants to keep track of a set of changes he/she is making to the trunk (or a branch) (i.e. create a Change Set) why should it be a 2 step process to commit then tag. Every SCM system I've ever worked with before has had the capability to apply a tag (or label) at the time of commiting the file to the repository, it just makes sense. This feature fits nicely into my orgainizations process. When a developer is working on a feature or fix that feature or fix is assigned a number. It is that developers responsibility to tag any revisions that are associated with that feature or fix with a tag of the form FIX## or FUNC##. The developer might commit some files one day and some more files the next day but they all are part of the same feature or fix. This in effect creates a Change Set for that feature or fix that is identified by the tag. When the release manager goes to create a new build or release he decideds what new features and fixes get added to the previous build (e.g. BLD11).. The new build is then created by applying the new build tag (e.g. BLD12) to all the revisions of the previous build plus the revisions with the desired feature and fix labels. A few consistency checks are made to make sure we aren't going backwards in the revision tree or that we aren't accidentally pulling in part of a feature or fix that we don't want in the build yet. It all works very well. There is generally no need for branching involved. It appears that CVS doesn't preclude us from using this process but it is a bit combersome and error prone to have to commit then tag. I'm sure that I can write the script to do it automatically but I'm curious why it isn't a feature of CVS already or why somebody else hasn't already created the script. Comments and suggestions are welcome and appriciated. Thanks Matt S. <Matthew_Schuckmann at Etec.com> wrote in message news:mailman.48.1107464148.282.cvsnt at cvsnt.org... > Is there a way to apply a tag at the same time as a commit? > With other SCM systems I have used labels/tags to create change sets but > those systems allowed adding a tag at the same time as commit the changes. > Is there anyway to do this with CVSNT or winCVS? (I'm not opposed to > scripts or WinCVS macros) Has anyone else done this? If not why not? it > seems like a pretty basic and very useful feature. > > Thanks, > Matt S. > > The content of this message is Applied Materials Confidential. If you are > not the intended recipient and have received this message in error, any > use or distribution is prohibited. Please notify me immediately by reply > e-mail and delete this message from your computer system. Thank you.