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.
"Bo Berglund" <bo.berglund at telia.com> wrote in message news:ctgq01d4717kealodtr9fc0v1094gdtbub at 4ax.com... > On Fri, 11 Feb 2005 11:32:01 -0800, "Matt Schuckmann" > <matthew_schuckmann at amat.com> wrote: > > >This whole discussion has brought us back to my origonal point, why can't > >you tag when you commit? Tony said it doesn't make sense, he also said that > >to use tags to discribe change sets is incorrect. > > > >However, you and Bo have both descirbed scenarios where change sets are > >described by tags and in those cases it makes perfect sense to tag the files > >your commiting at the point that you commit, when things are fresh in your > >mind and the chance of forgetting something is small. Tags can be moved up > >the tree as additional revisions for a fix are checked in and tags don't > >have to span the whole project. > > > > Not really so.... > Your supposition is that no commit is ever made without it being a > full solution to the problem at hand. I never said that, in fact I too would incourage people to commit early and often, several times a day if it makes sense, for all the same reasons that you listed. Tags can be moved, or so it says so in the documentation (-F option of the tag command). So why can't there be an option to apply a tag to all revisions being commited and another opiton (say -F) to force reassignment of that tag if it already exists on that file. In this way the tag would continuosly represent the head the work on that function or fix. This has nothing to do with the whole process I described before, it's applicable in many ways and it's a time saver and helps to prevent mistakes. > But this is not how many groups > use CVS, we are not doing thta at all. Instead we enforce that > developers commit their code at the end of the day so that it all is > in safe keeping on the server and will be backed up. In this case it > makes no sense tagging enything until you are done. > Furthermore, if tagging occurs automatically on commit then only the > committed file gets the tag and this is clearly wrong! Tags are mainly > used to tie together all files in a group that together compries the > time snapshot for a certain property (like a release or bugfix). So why can't tags be used to tie together a group of files that represent a fix or feature. Or hell just to help you keep track of what your working on. Nothing says that they have to span the entire project. > So > the tag should encompass *all* files needed to build that particular > version, not only the single or few files that have been committed. > > I think it is clearly WRONG to tag automatically. You seem to be stuck on the consept that tags are only usefull for indentifying a complete build, I would argue that that's not true. They can also be use full for indentifying a subset of the build that you may want to keep track of, or be able to checkout easily, etc. I never said automatically, the developer gets to chose if he wants to apply the tag, it would be an option for the commit command something like: cvs commit -m"" -t NewTAG -F The -t option applyes the "NewTAG" tag to all the files being commited. The -F option forces the "NewTAG" tag to move to the new revision if it already exists on a previous revision. If you've modified 3 files in your sandbox then 3 files will have the tag NewTAG. There maybe other files in the repository that already have the "NewTAG", perhaps files pertaining to the "NewTAG" work that were checked in the previous day. Like I said I've seen this exact feature in several other CM systems only they called tags labels. Why doesn't this make sense? you just applying a place holder to some files in the repository to help you keep track of your set of changes, and perhaps help someone else indentify exactly what goes into your work. And your doing at them most convenent, and least error prone time. The bug id comes close to doing this but you can't check out by bug id, you can't tag by bug id, you can't manage the bug id's in anyway, other than just creating them, and it's so new that no one supports them. > > If you really want to do this anyway you have always the possibility > to program the loginfo script on the server to do whatever you need, > for example setting up the condition that will be used by the > postcommit script later on. Postcommit can for example issue a tag > command all by itself and make that procedure work for you. > How would you get the tag name from the command line to the script? > > /Bo > (Bo Berglund, developer in Sweden)