Thanks for the response! 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.
James Carlson wrote: > John Ojemann writes: >> Clearly, it's ugly to do a single commit where all bugs appear in the >> log for every file; > > It is? I think it depends on the situation, and on what you put in > the bug reports. I should have elaborated ... 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. 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. >> 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? >> Provided there is a way to do what's described below, how then would a >> "recommit" be handled? > > 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. >> It's surprising that a "commit" can work on individual files, while the >> "recommit" can only work on all of the changed files at once (no >> apparent options). > > 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? Thanks again! - John
