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: > 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. This is about what Bo said. It doesn't really help you much to tag a few files; when you later retrieve this tag, you can't do much with it, as all the other files are out of sync. That's why you usually will tag all files required to do a build. Which is not that much of a problem. Your developers need to tag before and after their feature implementation. What they have done is the difference. Some files will have both tags on the same revision; these don't contribute to the difference. But I still think tags are not really a good choice for what you want. Maybe branches for every feature or fix do it better: - Developers can do intermediate commits. This gives them backup safety and history. It sometimes happens that during a feature implementation you want to look back what you had a few days ago. Branching gives you this possibility: you can commit incomplete code without disturbing anybody else. - You have a complete documentation where the feature development started, where it ended and what got changed underway. Retrieving the difference between start and end is more straightforward than without branches. - You get your tags almost the way you describe them. Every feature implementation sits on a branch with the feature name in it, like bFUNC345. But rather than a single point of a few files, this is a full branch and you can go back and see what has happened there, from start to end. - Merging the branches into a semi-stable development base can be done in a more controlled and flexible fashion. You can even let a branch sit for a while if you think it's not a good time to merge it in. > Yes every later feature is dependent on earlier efforts but only where those > efforts overlap, in most cases they don't overlap. If the changes in various branches don't overlap, merging them back in should be rather straightforward. > It would be nice if developers could base thier working sandbox on a known > good, at least marginally functional, sandbox. This shouldn't be a problem either way. You just have to make sure someone coordinates what gets merged into that branch (be it a dedicated "development base" branch or the main branch). Gerhard