I do realize it is over a month, but ... I managed to get git status reliably under 5 seconds (most of the time under 1 second). First improvement was an accident, as I installed some other stuff from cygwinports, my git version got updated to 1.8.x and it was already way better. Second, I have set a config option core.preloadindex to true which reduced it further.
My config: - win7-64 running as VM, - git comes from cygwinports - cygwin itself is 64bit flavour - hd is ssd - also modified windows registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management set to 1 --pawel On Wed, Feb 5, 2014 at 1:46 AM, Jeff Hardy <jdha...@gmail.com> wrote: > I pushed some updates to the repo that should make it work now. One > piece that is currently missing is the DLR assemblies. To get those, > download https://www.dropbox.com/s/bpg05pk50xyadgz/dlr-1.5.0.zip and > copy the 'lib' directory (in dlr-1.5.0) to > Util\References\DynamicLanguageRuntime.1.5.0 (that is, you should have > Util\References\DynamicLanguageRuntime.1.5.0\lib). I haven't tested > 2012 but it works in 2013. > > - Jeff > > On Tue, Feb 4, 2014 at 10:40 AM, Markus Schaber <m.scha...@codesys.com> wrote: >> Hi, Jeff, >> >> Okay, I'll try to have a look at it later. >> >> I've got mixed results with MonoDevelop/Xamarin Studio in the past, >> including crashes while trying to load "normal" solution files (which work >> fine with VS, VS Express, MSBuild, VisualBuild and SharpDevelop)... >> >> Best regards >> >> Markus Schaber >> >> CODESYS® a trademark of 3S-Smart Software Solutions GmbH >> >> Inspiring Automation Solutions >> >> 3S-Smart Software Solutions GmbH >> Dipl.-Inf. Markus Schaber | Product Development Core Technology >> Memminger Str. 151 | 87439 Kempten | Germany >> Tel. +49-831-54031-979 | Fax +49-831-54031-50 >> >> E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: >> http://store.codesys.com >> CODESYS forum: http://forum.codesys.com >> >> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade >> register: Kempten HRB 6186 | Tax ID No.: DE 167014915 >> >>> -----Ursprüngliche Nachricht----- >>> Von: Jeff Hardy [mailto:jdha...@gmail.com] >>> Gesendet: Dienstag, 4. Februar 2014 10:01 >>> An: Markus Schaber >>> Cc: ironpython-users@python.org >>> Betreff: Re: [Ironpython-users] Splitting up the IronPython repo >>> >>> I did most of the work on my MacBook, just running MSBuild from the command >>> line; it might still need some tweaking to work from VS. The main thing is >>> making sure all of the properties are set when just loading the projects >>> (not >>> using Build.proj as a wrapper). If you look in the .csproj file, it tries to >>> populate a property (the filename of the platform-specific properties) and >>> then import it; my guess is that for some reason that is not getting set >>> properly and staying at ''. >>> >>> Unfortunately VS and MSBuild are not exactly the same; the environment and >>> pre-set properties are different depending on whether it is run from the >>> command line or VS. I do remember opening it in VS 2013 though, to make sure >>> that it worked, but it's possible I changed something since then or that >>> 2012 >>> and 2013 are slightly different. I don't want to require 2013, though. (I'd >>> also like to open cleanly in MonoDevelop/Xamarin Studio, but it tends to >>> mangle the csproj files in unfortunate ways.) >>> >>> - Jeff >>> >>> On Tue, Feb 4, 2014 at 8:21 AM, Markus Schaber <m.scha...@codesys.com> >>> wrote: >>> > Hi, Jeff, >>> > >>> > I tried to open the IronPython solution file using Visual Studio 2010 Pro >>> and 2012 Express for Desktop. Both failed to open the IronPython, IronPython >>> and IronPython.SQLite projects with the following error messages: >>> > >>> > D:\Contribs\Ironpython\ironpython-only\Src\IronPython\IronPython.csproj : >>> error : Unable to read the project file 'IronPython.csproj'. >>> > D:\Contribs\Ironpython\ironpython- >>> only\Src\IronPython\IronPython.csproj(516,3): The value "" of the "Project" >>> attribute in element <Import> is invalid. Parameter "path" cannot have zero >>> length. >>> > >>> > D:\Contribs\Ironpython\ironpython- >>> only\Src\IronPython.Modules\IronPython.Modules.csproj : error : Unable to >>> read the project file 'IronPython.Modules.csproj'. >>> > D:\Contribs\Ironpython\ironpython- >>> only\Src\IronPython.Modules\IronPython.Modules.csproj(149,3): The value "" >>> of >>> the "Project" attribute in element <Import> is invalid. Parameter "path" >>> cannot have zero length. >>> > >>> > D:\Contribs\Ironpython\ironpython- >>> only\Src\IronPython.SQLite\IronPython.SQLite.csproj : error : Unable to >>> read >>> the project file 'IronPython.SQLite.csproj'. >>> > D:\Contribs\Ironpython\ironpython- >>> only\Src\IronPython.SQLite\IronPython.SQLite.csproj(160,3): The value "" of >>> the "Project" attribute in element <Import> is invalid. Parameter "path" >>> cannot have zero length. >>> > >>> > Some of the properties associated with the solution could not be read. >>> > >>> > Best regards >>> > >>> > Markus Schaber >>> > >>> > CODESYS® a trademark of 3S-Smart Software Solutions GmbH >>> > >>> > Inspiring Automation Solutions >>> > >>> > 3S-Smart Software Solutions GmbH >>> > Dipl.-Inf. Markus Schaber | Product Development Core Technology >>> > Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | >>> > Fax +49-831-54031-50 >>> > >>> > E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS >>> > store: http://store.codesys.com CODESYS forum: >>> > http://forum.codesys.com >>> > >>> > Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | >>> > Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 >>> > >>> >> -----Ursprüngliche Nachricht----- >>> >> Von: Ironpython-users [mailto:ironpython-users- >>> >> bounces+m.schaber=codesys....@python.org] Im Auftrag von Jeff Hardy >>> >> Gesendet: Montag, 20. Januar 2014 10:10 >>> >> An: ironpython-users@python.org >>> >> Betreff: [Ironpython-users] Splitting up the IronPython repo >>> >> >>> >> One of the big issues with working on IronPython is the size of the >>> >> git repository (specifically https://github.com/IronLanguages/main) - >>> >> git does not like really big repos, especially on Windows. Part of >>> >> the problem is that the repository includes: >>> >> >>> >> * The DLR >>> >> * IronPython >>> >> * IronRuby >>> >> * Two copies of the Python stdlib >>> >> * The Ruby stdlib >>> >> * WiX >>> >> * and a bunch of reference assemblies >>> >> >>> >> Even on a fast machine, 'git status' takes several seconds to return. >>> >> I believe this is because it was originally a TFS repo, which can >>> >> scale to handle bigger repos by using a bigger server. With git that >>> >> option doesn't exist - if the repo is too big, the only option is to >>> >> split >>> it up. >>> >> >>> >> I've created two repos - https://github.com/jdhardy/dlr and >>> >> https://github.com/jdhardy/ironpython-only - that contain just the >>> >> DLR and IronPython, respectively. In them, git calls are nearly >>> >> instantaneous, which makes working with it a lot less painful. >>> >> >>> >> There are other advantages - the DLR can get its own release cycle >>> >> and packaging, and IP can then depend on a specific version of the DLR. >>> >> Each project has a modified version of the IronPython build system >>> >> that makes it easy to build for other platforms (iOS, Android, Win8, >>> >> etc. - they still need to ported and tested, but the builds are easier). >>> >> >>> >> I did most of the work using Mono/xbuild, so I know it works there >>> >> (except for a bug in Mono's .NET 4.5 support), but it has some errors >>> >> on Windows that I need to sort out. >>> >> >>> >> Once I get my Windows box back and get some time to fix the few >>> >> remaining issues, I'll move the repos to the IronLanguages account >>> >> and use them for development of a real DLR release and IronPython >>> >> 3.0. Any more 2.7 releases will come out of the existing repo. >>> >> >>> >> One downside is that copying patches between 3.0 and 2.7 is going to >>> >> be extra work, but 3.0 will solve so many problems with strings that >>> >> I think it will quickly become the more common target. In general >>> >> Python >>> >> 3 momentum is picking up so it's a good time (some recent >>> >> hand-wringing >>> >> notwithstanding) to try and have IronPython 3 in the right spot at >>> >> the right time. >>> >> >>> >> I haven't really addressed IronRuby because, for intents and >>> >> purposes, it's dead. >>> >> >>> >> All of that said, if anyone has any objections I'd like to hear them. >>> >> The split repos work well for me but I'm curious if others prefer the >>> >> combined repo. >>> >> >>> >> - Jeff >>> >> _______________________________________________ >>> >> Ironpython-users mailing list >>> >> Ironpython-users@python.org >>> >> https://mail.python.org/mailman/listinfo/ironpython-users > _______________________________________________ > Ironpython-users mailing list > Ironpython-users@python.org > https://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
