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: > All this would tell you is that FIX145 likely worked with TAGGED_BUILD_15 > but given my comment above that's really not all that useful, you'd still > have the problem that FIX145 doesn't work with TAGGED_BUILD_16 that you'd > have figure out and fix. Be it a tag over the whole source or a branch, that's something important to me. If I check out the fix (based on tags on only the fixed files) and it doesn't work, I don't know whether the developer simply screwed up or whether that's a problem because the other files changed in the meantime. If I have the full project tagged and it doesn't work, I know that the problem is with the fix and not with the other files. That's important information for me as integrator. > Yes we created a proceedure that relied on some scripts that we wrote, but > those scripts depended on simple features that are common to most CM > systems: > 1. The ability to apply a Symbol (label/tag whatever you want to call it) to > one revision of a file. > 2. Logging feature that tells you what symbols are on what revisions of what > files. > 3. The ability to checkout files by revision number or by symbol. > > That's it and CVS does support these requirments. You could very easily write a script that does exactly what you need. It would be used by your people to commit changes. It can make sure that a proper feature/fix code is always given and that it is always placed in the same location (say the first line of the comment, where the rest of the comment goes in subsequent lines). That's the beauty of the command line :) You could even put that in a file with the name cvs.<your favorite script extension>, and pass all other arguments straight through. Then this whole thing is completely transparent. > Yep and that's what you'd want, some at BLD1 and some at FIX3, because > that's what you asked for. You'd want BLD1 with FIX3 appended to it. I > think the formal statement for this is something like: The set of all files > with any of the given symbols where if multiple symbols exists on a file the > symbol on the latest revision is selected. I would consider something like this as dangerous, and wouldn't use it. But that's a matter of taste... >> 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. > > Sorry I miss understood what you meant by various revisions of a file, I > don't want to have the same symbol on multiple revisions of the same file, I > never asked for that and if I did I'm sorry for the confusion. Yes, this created confusion on my part, and pretty much invalidates the rest of my post. > I just want a symbol on one revision of some (or all) of the files. And > I've verified that tags have this cabability. Yes, that's what they are. But you can't really get the change set for a fix with this method, right? Unless you know which tag it started out with. Which is not an information that's part of the files; it would need to be kept separately. > btw, BugID's in CVS do work the way you described, i.e. a bug id can exist > on multiple revisions of the same file, however I still don't understand why > anyone would want this, other than for multiple branches, which is another > whole mess. I've never worked with bug ids, and haven't even looked too closely at them. But marking several revisions with a bug id would give you the possibility to retrieve the set of changes that this bug fix takes. And it gives you the possibility to review the history of the fix. > As for why this would be useful. You've never applyed a symbol just to keep > track of one or two files at a given revision, or to keep track of a group > of files that you are working on? I've done that, but this tagging wasn't restricted to committed files. When I do something like this, I usually tag a set of files that belong together, even though some of them I didn't change through a commit. But I find myself using mostly branches when I need to do something like this. Otherwise the interdependencies become too difficult and error-prone to manage. > In your head is often different from what ends up happening in reality. > You've never abandoned a change because it didn't work or branched a file > because you thought you might change it but ended up not changing it. I usually don't branch a /file/, I branch a /project/ (or sub-project). I have abandoned changes /on the branch/ -- which only brings me back to an earlier revision on the branch. And of course in doing so (branching a project) I branch many files that I may not touch. The branch is not something that says "I have something to change on this file", it says "I have something to change on this project". It goes like this: "I need to implement FIX134. This is more than just correcting a string, so it's likely to take a while and cause me to run in a few circles. This is likely to create unstable intermediate builds. So I create a branch on the project, and put my sandbox on the branch. Now I can work on the fix, on any file in the project, without disturbing anybody else, commit test code and incomplete code as I need it. After I'm done and sufficiently tested I merge the code back to wherever it should go." This leaves a complete trail of FIX134 in the repository -- where it started, where it ended, what it changed. While I'm working on it, my sandbox is on the branch. I don't have to worry about adding the correct label to the commits, this is implicit in being on the branch. And I can delay merging it back, if that should be necessary (and sometimes it is). (Of course this is one of the things where people started to think about alternatives and developed subversion, where the cost of branching is not dependent on the number of files branched.) > But your not likely to promote or distribute that alternate build. Further > more in a project of upwards of a thousand files your talking about a lot of > tags and branches. Yes you could divide the project up into sub projects but > wait if you don't tag all the files in all the projects you could end up > making a change in sub project A that could then break later on because > somebody changed something in sub project B that you change in project A > depended on, sound familure. In a project that big I'd probably separate it into sub-projects, and use a similar mechanism to coordinate between sub-projects. Like project A depends on revisions 2.3 of project B and 2.7 of project C. Then bumping the published revision of a project is a bigger event and needs to be coordinated with the other projects. (Which includes working with stubbed interfaces and the like...) With a project of this size, I use branching heavily. Individual branches for such fixes, development branches, test branches and "internal release" branches, and of course release branches... One of them is the trunk, often the main development branch. Gerhard