Vladimir Marek <Vladimir.Marek at Sun.COM> writes: > Hi, > > please let me forward Vlad's comment's to scm-migration-dev, where we > can find broader audience (and it's also going public). > > I'll attach my comments inline. > > > On Thu, Jul 17, 2008 at 03:37:13PM +0200, Vladimir Kotal wrote: > >> Since the (2nd) e-mail from Mark J. Nelson I have started the conversion >> to Mercurial for my workspaces. So far I have identified the following >> dissatisfiers for RPE/general use: >> >> 1. bug in wx2hg when converting to already existing Mercurial workspace >> CR 6726003 >> - level of annoyance: low >> 2. Mercurial is slow >> listing files which have changed in a workspace (hg status) takes 20 >> seconds on a machine with very fast disk subsystem. Compare it to 'wx >> list' which takes under 1 second. Cadmium does not really help since it >> is just a wrapper for internal hg commands. wx is dead and only reports >> error message about not supporting Mercurial workspaces. >> - level of annoyance: painful
As you state, (and the other, long, thread states too), this is almost entirely 'hg status', in profiling runs I have. There are issues in other places, but they're close to in the noise in comparison. > This corresponds with the un-willingness of mercurial people to develop > 'hg edit', or similar concept to mark files of interest. (they might not > need it, or they don't see that saving tens of seconds is a reason for > some level of mercurial complication) > > The cdm 'hg list' takes actually longer than 'hg status' to finish. (It > takes ~90sec on my uncached workspace over NFS). That seems odd, given most of the time used by cdm's list is used in status(), it may be that we have to do more work (some of it obvious, some of it not), but in my tests it hasn't been nearly that bad. > I would personally also like to see something like > > hg cedit (cdm edit ?) > hg cstatus (cdm status ?) > hg cunedit ? > > Do you think that it is not reasonable to request that ? I tried to > fully "warm up" my workspace, and I got to 6s for 'hg status'. 10 > minutes the same command took 32s. No other load on the machine. So the > workspace "cools down" quite rapidly ... I haven't seen that, either, my working data gets into cache and tends to stay there, barring outside events. That proposal is similar to another that was made to us off list, it's being thought about, for cdm. Whether we can get it, and everything else, done in 2 weeks may be another matter. >> 3. history (comments) is aggregated. this means doing most of the >> backports will be time consuming/difficult. >> - level of annoyance: painful > > We had some discussion about this one. The problem is that if you have > several CRs fixed in one changeset, you are not able to distinguish > which file was modified on behalf of which CR, it might complicate your > task while backporting just this one CR. The Suggested Fix note in bugster is, I'm told, *meant* to only contain the diffs for the specific bug in question (unless utterly inseperable from others). That may help you. > Now the question is, shouldn't the original putback be split into > several smaller ones if possible ? Can we have several changesets per > one RTI ? If yes, I would say that we should encourage people to do so, > and explain how it can be done. If no, backports will be more difficult > than before. I have no useful comment regarding that. >> 4. lack of backporting guide from ONNV to ON10 >> - level of annoyance: mild, will become high after snv_97 Or that. >> Possible solutions: >> >> 1. simple, just fix it >> 2. rewrite Cadmium [1] to behave like wx Somewhat, but not quite. I think we could possibly achieve something similar, but "like wx" is far too strong for how similar we possibly could be. >> 3. live with it / force NRE to update Suggested fixes in Bugster >> diligently They should be doing that *anyway*. >> 4. write one You guys (RPE), do backports, I assume. I'd suggest that you folks would be the better placed to write this. >> I am searching for volunteers to help with #2. This will also solve the >> problem with noise produced by hg when run in previously built workspace. You'd think asking us about that earlier would have been a better option than seeking others to try and do it. >> In overall, I think we (as RPE) have underestimated the impact of the >> transition. It's time to play catch up. If it helps you, I get the impression that the vast majority of people have done similar. You're not alone. -- Rich
