John Ojemann writes: > I guess the reason I'm even looking at this is that in RPE, we use the > file history and version specific info a lot, so this transition is > rather painful for many of us, and I'm just trying to ease that pain as > much as humanly possible.
We use it quite a bit in development as well in determining when a problem was first introduced and trying to decipher what the original author intended to do. I don't think you're alone in that. I don't think the problem is that bad, though. CRs are supposed to list at _least_ the files involved, and should also include diffs, so once you're down to a single changeset (through use of "annotate" and "history"), you may have to look at a few of the CRs listed -- usually, it's possible to narrow the list just by looking at the summaries. One of these things is not like the others. > There are many instances (or at least there have been in my travels) > when several related bugs are being addressed at the same time, when not > all bugs modify all files, and some bugs make no sense to be listed in > the history for some of the files. Might be the nature of the products > I support, but it does happen none-the-less. The "make no sense" bugs are the easy case. Ignore 'em. They're the first thing to eliminate when looking through the comments in the history in order to identify the offending CR. > In addition, even though a "bug wad" of unrelated issues is often not > the right thing to do, in RPE case it often can be ... If I need to get > 10 bugs into marketing release in order to get them "soaking" for port > back to an Update (maybe as result of a handful of escalations for a > particular product), it's not efficient to have to submit 10 individual > RTIs; not to mention the CRT burden on the other end. It's probably a case-by-case issue. > >> but is it acceptable to do an individual commit for > >> each file, and then do a single push? > > > > Yes, you can do that if it's necessary. I wouldn't go wild with it. > > Having dozens of changesets in a single push would also be irritating. > > This is actually what prompted me to ask the question to begin with ... > If it's done with a single "push", is this actually a problem? Who > would this ultimately irritate? Wouldn't it be better than the same > number done individually? I think it'd irritate anyone looking at the history for the same reason that a pile of tiny putbacks in Teamware was mildly irritating. > > A "recommit" will collapse all the changesets into one, which is how > > things ordinarily work in ON. > > A wx redelget did this "per file"; which would help in above example. That's gone, because Mercurial just plain works differently. I would suggest maintaining separate workspaces for each change (or block of changes to be committed as one changeset), and then merge those workspaces into one before integrating. It'll probably be quite difficult to achieve, given that you need to pull/merge/commit/recommit if there are any pushes between the time when you do this (busy)work and when you finally push to the main gate. > > The versioning in Mercurial is not per file. It's on the repository > > itself. Thus, I don't think that doing a "recommit" on individual > > files makes much sense. > > Yes, but is there a way to easily "back out" the initial commit (per > file) in favor of a new one? You can do "hg rollback" to undo the most recent commit. I haven't tried it yet, but that _might_ work right with recommit, and might be a better method than the multiple-workspace one I suggested above. I just doubt that in the long-term it's worth the effort you may need to apply. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
