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.
Arthur Barrett wrote: > From every company I teach this stuff at I learn new things - however > most of our customers approach us for our commercial software and > training because they also have a CM manager/QA manager that already > "knows" all this stuff, and they are (in essence) picking our software > and services because we think like them. For me - learning how to > communicate this stuff effectively to people who don't live an breath CM > and CM best practice is the challenge, and discussions like this help me > a lot. I put this on top, because I think I see a part of why we seem to be talking of different situations. Most of my CM experience with bigger teams is in initial software development phase (working with a software development company that often got brought in when things were already much too late or burning hell), the phase where big changes are the norm, not so much in production development, where small incremental changes probably are more frequent. I think the probabilities for conflicts in changes may be different in these situations. >> I understand the purpose of item 2, but I don't understand how you would >> (easily) "back out" a change set and put it into a later revision. >> That's the part with the actual commands I asked you to provide earlier >> in this message. > > There are many ways, here is an example from the eBook: I think there is a market for the eBook alone (supposedly cheaper than the full licensed package). Of course, I don't know how much of the eBook is about general use of the tools and how much is about the specific tool set and integration you're selling -- and I also don't know how many of those who would buy the eBook are people who otherwise would buy the whole package :) > For example, to rollback a commit that you just performed: > > cvs update -j @commitid -j "<@commitid" filename or modulename > > "<@commitid" revision before that commit > > @commitid revision of that commit I figured something like this, but then it seems that the whole process has a good potential to become quite a bit contrived. (BTW, isn't that a double j merge -- the one you said "stop using double j merges (just stop, no if's but's or maybe's - they are not needed)"? :) You wrote earlier: >>> you back out the 3335 change (one line command) and "fix" 3334 and >>> commit, then re-add the 3335 change (another 1 line command) and >>> re-commit 3335 This is how the 'back out the 3335 change' looks to me: Determine which commitids belong to that change. It may be one or several, but I don't know (in the general case, where it wasn't me who made that change), so I have to find out. AIUI I have to run a cvs log, search the output for "bugid: 3335" and collect all revisions that belong to that bugid. That gives me the one or more commitids associated with the bugid. Then I run one or more (depending on how many contiguous sequences of commits were) of the double j merges to 'merge out' the 3335 commits. This probably works reasonably well if these commits are in one block, but I imagine that this may not be that simple if they are not. Similarly for re-adding 3335. If 3334 were on a branch, there would be no need to back out 3335: just fix it on branch dev_twinkie_3334 and merge the fix back to dev_twinkie. So I guess in such a scenario, deciding whether or not to put a change on a branch depends on the need to have the change accessible separately (if that's not necessary, we can use a non-reserved process), the probability of something like this happening, and the amount of effort involved of performing the above -- all that weighted against the effort of creating (and managing) a branch. I guess when you are in a situation of working with some ten developers on maintaining software with hundreds of modules that is already reasonably settled, the odds of overlapping changes are indeed low. But there are other scenarios where these odds are not negligible, and branches become more attractive. Gerhard