Community
Participate
Working Groups
Build Identifier: org.eclipse.egit.ui_1.2.0.201111041821, Eclipse 3.7.1 AS IS: I've tried to close SWT libraries as described here: http://wiki.eclipse.org/Platform_UI/How_to_Contribute / http://wiki.eclipse.org/Platform_UI/Git#Development_in_Juno I needed more then 3 attempts to get it done, simply because the process was interrupted in the middle due the small timeout set in preferences (60 sec). TO BE: There should be used different timeouts values for different Git commands, as many of them can be long running by default (clone/push etc). In MercurialEclipse, we have a dedicated "Tomeouts" preference page, see attachment. A default value of 60 seconds doesn't fit even such "small" repositories as SWT (~100 MB?). I don't want to think what would happen with a larger repos. So for some operations timeout should be increased. Current timeout will be a showstopper for every enterprise Git user. Reproducible: Always
Created attachment 206501 [details] Screenshot of MercurialEclipse preference page
I can't reproduce this. I cloned this repository from Germany (AFAIK Eclipse is hosting in Canada) over a 3 MBit/s DSL line in a couple of minutes. It took around 4 min to download the data and another 3 min to process the deltas. BTW the default timeout is 30 sec not 60 sec. If you just have a slow connection no timeout should occur, only if no data is transferred for a period of at least 30 sec the timeout will interrupt the fetch process. I think we don't need different timeout parameters for different operations as this timeout parameter is not the maximum overall time of the operation but the maximum accepted period without data transfer. So if you transfer a large repository but the data transfer doesn't stop for more than 30 sec no timeout should occur. If you frequently experience interrupted remote operations with this timeout value this means your network link isn't reliable (i.e. frequently stops transferring data for at least 30 sec). I don't understand why this should be a show-stopper for enterprise git users as I would expect that enterprises have better networks than the one I have at home. Increasing the default timeout value may help when you have an unreliable network link but under normal conditions an overly long timeout isn't desirable as users which e.g. are waiting for a transport over a broken Wifi link would have to wait for a long time until the operation would recognize the broken link and interrupt the transport operation.
