Vladimir Kotal writes:
> James Carlson wrote:
> > Vladimir Kotal writes:
> >> - 'hg edit' adds new entry
> >
> > I think that might be deferring a bit too much to SCCS. Mercurial
> > (like CVS and a few others) is different. You don't have to "check
> > out" files in order to edit them. They're writable all the time.
>
> I am very well aware of that.
Then I'm concerned that the proposed 'active' list will simply do more
harm than good: it wasn't perfect with Teamware, but you _really_
can't rely on it with Mercurial.
> > As much as I miss the old 'active' list in wx, and wish it were here
> > for Mercurial, I've also grown used to how hg works. I think using
> > the tool the way it was meant to be used is probably the better
> > long-term path.
>
> While it is okay to change the habits in terms of working with a
> different SCM, it's really a blocker to wait tens of seconds for
> frequently executed commands which in previous SCM took under 1 sec.
It's not *that* bad when the cache is reasonably warm:
% time hg status -mardn usr/src
usr/src/uts/common/io/bridge/bridge.c
4.50u 2.03s 0:07.52 86.8%
%
> It all comes down to how much does one allow different SCM to permeate
> to working habits. Should I just stick with running 'hg list' less
> frequently and learn the source code paths by memory ?
I think cscope and tags are good for the memory part, though I do find
myself running "hg status" as the first thing in the morning when I
enter a workspace and need to remind myself what I've been working on.
> You have spent significant amount of time working on/with the SCM tools;
> maybe you can tell us your recipe how to cope with the change in terms
> of working with a workspace ?
- Don't use "hg active". It's painful. Use "hg status" and/or "hg
outgoing" for most tasks. The native hg commands also don't
bother contacting the parent.
- Live with the fact that "hg status" will probably be cold the
first time you use it.
- Keep notes. Better yet, keep good notes. ;-}
- Use cscope.
> > (And if hg needs to cache lists of modified files in order to speed up
> > common queries, then it needs to do that not just for us but for all
> > Mercurial users. It's a common problem, not something special like
> > 'cstyle' or 'rtichk' that we have to layer on top.)
>
> I agree, it's only about finding good short term solution.
>
> The cdm workaround is supposed to look like this:
> - use manually maintained active list
> - majority of cdm commands use the manual list
> - with exceptions such as pbchk which need to be always correct
> (pbchk usually takes long time to run anyway)
> - hg commit/push will use the real active list
>
> Different approach might be adding cdm command which would sync manual
> list with the real list.
I think I'd end up using that 'sync' command more often than anything
else, including just dumping the active file.
I can remember when I've done "sccs edit," because it's a rather
unusual operation. I have more trouble remembering when I modified
and saved a file.
> Yes, all the workarounds sound a bit desperate ;/
>
> Also, now that webrev uses hg-active (via hg_active_wxfile()) it got
> slower as well.
Yes. Using an explicit list supplied by the user would help there.
--
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
