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 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). 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 ... > 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. 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. > 4. lack of backporting guide from ONNV to ON10 > - level of annoyance: mild, will become high after snv_97 > > Possible solutions: > > 1. simple, just fix it > 2. rewrite Cadmium [1] to behave like wx > 3. live with it / force NRE to update Suggested fixes in Bugster diligently > 4. write one > > 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. > > In overall, I think we (as RPE) have underestimated the impact of the > transition. It's time to play catch up. > > > v. > > [1] > http://adorus.czech.sun.com:8080/source-onnv-clone/xref/src/tools/onbld/hgext/cdm.py -- Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/scm-migration-dev/attachments/20080717/2d0f21b4/attachment.bin>
