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: >> 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. > > I think that it would be a safe assumption to first checkout, or update to, > the last tagged build before the tagged subset of files, this has worked > just fine for us for 2 years. Or maybe you don't really care, maybe the > changes are self contained and you don't really care what version the rest > files are at just so long as they work. > If your working in the paradigm I described before the tag before the > changes would be the last build tag or the last fix tag. This is not how I understood your process so far. You said that you wanted the changes labeled because it gets decided at some point whether they go into the next stable release or not. Say you have TAGGED_BUILD_15. Then you implement FIX145. Then someone creates the next TAGGED_BUILD_16 /without/ FIX145, for whatever reason. Then someone wants to verify FIX145, checks out TAGGED_BUILD_16 (the last tagged build, that's the assumption you gave) and FIX145 -- and boom, it doesn't work because something in TAGGED_BUILD_16 messes with something FIX145 needs. So you need additional information that FIX145 depends on TAGGED_BUILD_15 and not on the /last/ tagged build. So why not tag the whole bunch of files with FIX145? It seems to me that you guys created a procedure based on some available and created features of a version system. Now you want to use a different one, emulating the same behavior. Sometimes that works, but IME usually you need to adapt procedures to the tool you are using. No use in fighting the tool -- if it isn't close enough, get a different one. > Oh and wouldn't it be cool if you could if you could give checkout or update > several tags and it could automatically figure out what set of file > revisions is the most update given those tags. If you have a somewhat consistent tagging procedure, these tags have a sequence in time. If you update to them in the correct sequence order, you get what you want. cvs up -r BLD1 cvs up -r FIX3 However, if you didn't tag the whole project with these tags, you now have some files on BLD1 and others on FIX3. >> This could be different if cvs had the option to assign a single symbol >> to various revisions of a file. ... > Hey you finally got it this is exactly what I want and yes CVS can almost do > this it just takes a minimum of two commands to do it, maybe 3 because I > don't think that commit displays the new revision numbers added. Not really, if I understand you correctly, because cvs can't assign a single tag to multiple revisions. That's not the way tags work in cvs. > Why not just add a couple of options to the commit command and make it 1 > command, like everybody else does. It's not anything ground breakingly new. It's not, but it's also nothing that's really worthwhile for the way cvs tags work (or better, for the way I understand them to work). > Forget why I want the tag there and what I'm going to do with it. You seem > to be hung up on the way your used to working with CVS. No, I don't think so. I just would like to understand what could be done with this feature that couldn't be done better otherwise. You said above "this is exactly what I want", but that means that cvs is not for you. You can't tag multiple revisions of a file with the same tag, which would be necessary for that scenario I described and that you said is exactly what you want. Forget what you _did_ so far with what you call "tags". It seems you need to understand what tags are /in cvs/. If I understand you correctly (and you seemed to have confirmed that by saying "this is exactly what I want"), you don't want cvs tags, you want something else. > Actually the first time you check in (commit) is the point at which you > really start to diverge from the stable build and you may or may not revisit > that file. I start to diverge (in my head) the moment I start working on a feature. I know I will change _something_, and thus I create a branch. > If you do you just move the tag/label/symbol/bugid up to the next > revision, it's sort of like a floating label (but not really). Further more > you may decide to abandon the changes before ever commiting so then in your > senario you've got a dead branch/tag sitting out there taking up space. This shouldn't happen too often. If it does, there's probably something wrong in the feature/fix assignment process. > Why go through the extra work to create a tag/branch across the entire > repository when all you really care about is just a few files. Because these files depend on the others. You create an alternative build, not just a set of files you worked on. (See the top of this message.) Much of the confusion in this discussion seems to stem from the fact that your build process makes a number of assumptions that were not clearly described. As in that a fix compiles with whatever other files are around. Or as in that the fix lives in the context of the last stable build, but then you say that it may depend on other fixes not in the last stable build (with is something different already) and you also say that the purpose of the whole thing is to select what goes into the next stable build, so a fix might not go in, which then makes it dependent not on the last stable build but the one before (or even earlier). Figuring all that out depends on a whole lot of additional infrastructure and documentation -- or it worked by chance, or the problems simply got worked over without ever noticing them explicitly. Gerhard