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.
Matt Schuckmann wrote: >> 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. "They can be useful": Kind of, and kind of not. When someone checks out such a tag, the result is of a very limited use. You can't build it because all the other files are missing. So you can't even verify that it works. If you check out the other files to build it, you don't know which revision of the other files to get. The tagged files usually depend on interfaces in the other files, and if these change, the tagged files would have to change, too. This is why Bo said that a tag usually needs to tag everything that's necessary for a build, because even though you maybe changed only three files, the changes make only sense in the context of the other thirty files as they were at the time you changed the files. Then there's the difference aspect. You can say that the tag allows you to create the difference, what got changed by the fix. But in this case you'd have to have a tag from before the fix and one that marks the end of the fix. How would this work with an automatic tagging feature? You still would have to tag the whole repository before you start working on the fix. Or you would have to remember to do that with every single file you start to work on -- dangerous, at least. Just an option for commit that adds a tag doesn't give you this. So the solution for this would also be to tag the whole set before and after the fix, not individual commits. (This could be different if cvs had the option to assign a single symbol to various revisions of a file. Then you could mark all commits for a feature or fix with that symbol, and the complete change set for that feature would be the addition of all commits with that symbol. This could work, but it is not how tags work in cvs. This can't really be done with cvs so far, in this way, to my knowledge.) So however you look at it, an auto-tag option for commit seems not to make a lot of sense, considering how cvs handles tags. > 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. Actually, the best thing is to create the branch before starting to work on the fix, and create it on the complete source. (Of course there are special considerations for very large projects; then you probably should create pseudo-independent sub-projects.) > 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. This is not really the most logical point for me, at least for tags and branches (no experience with bug ids). IMO the most logical points in the lifetime of a fix or feature implementation are when you start working on a feature or fix (that is, when you start diverging from the current stable state), and when you have a working implementation (that is, when you think you have reached a stable state again). Individual commits are only arbitrary points in between those two. Gerhard