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.
Hey, there could even be another option for the commit command, call it the -b option, which creates a branch with the provided tag name. This was also an option of ther CM systems I've used. This fits in nicely with the senario that Gerhard Fiedler suggested, a senario that I'm drawn to more and more. All I'm saying is that if you want to use tags or branches or bug id's to create a subset of your files you should be able to create (or add to) that subset at the most logical point i.e. when you commit. If it is a seperate command to do this you are more likely to forget something or do something else wrong. Matt S. "Matt Schuckmann" <matthew_schuckmann at amat.com> wrote in message news:cuqqbt$69o$1 at paris.nodomain.org... > > "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) > >