On Thu, 26 Feb 2009, Douglas Philips wrote:

> On or about 2009 Feb 26, at 9:30 AM, Marko K?ning indited:
> > Yeah, I can confirm this: my 700 MHz W2k machine needs about 7 to 10
> > seconds every time I try to synchronize a repo or have a look at the
> > ChangeLog until the corresponding dialog actually appears on the  
> > screen...
> > Quite annoying. From that point of view a seperate application (which
> > keeps all it's DLLs loaded) would make more sense to me, just like  
> > WinCVS
> > (but luckyly TortoiseCVS is not that slow). Python itself is a real  
> > show
> > stopper here.
> >
> > Actually even on my WXP machine (2.1 GHz P4) THG is not really  
> > fast... :(
> 
> Also as point of data, when my work team was using
> CVS they would keep WinCVS open all the time.
> 
> When I use THg, I use it from the command line.
> When I first started using THg (around 0.4)
> I would try to keep the windows open all the time
>      (because of the delay it took to
>       to open "on demand")
> but they aren't written to handle that usage.
> They are written to get in and get out.

Have you tried the latest nightly build?  Did it improve app startup
times at all?  If not, I'll probably leave those demandimport changes
out of the 0.7 release just to be extra safe.

> This is why I had such hope for the
> GSoC project last summer that was going
> to provide a WinCVS-like experience.
> 
> To be clear, I still see value in the
> existing Right-Click "on demand" model,
> and my work group has been willing to put
> up with the performance hit and lack of
> unified WinCVS experience because while the
> GUI might be slower than WinCVS, the
> underlying operations are MUCH faster.

I'm open to an uber app that welds dirstate maintenance, push/pull,
and the history browser, if it's done well.

> IMHO THg needs to solve the performance
> issues before 1.0. How that fits into
> the other pre-1.0 priorities is not
> very clear to me, nor is it clear
> where it should fit in...

The overlay issues could be improved by using a C++ shim, a smarter
dirstate walking algorithm, and more aggressive cacheing (would
require OS notifications when files changed).  Each of these is a
major project.

At this point, it's all about priorities.  Going into the 0.8 July
release, my main priority still is growing the user base.  That means
useability, documentation, translations, ports (Win64, MacOSX), and
binary packages for non windows platforms.

After 0.8, most everything is up in the air.  I think we're nearing
feature completeness for a 1.0 type release.  There's no big gaping
holes in the coverage as far as I can tell.

--
Steve

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Tortoisehg-discuss mailing list
Tortoisehg-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss

Reply via email to