>> Regular svn updates (with short delta) are acceptable fast
(5-10min under Windows), but in the cases when an old version is needed or to do svn
switch, the updates are much longer:
>> svn update -r21899 (from r21862, 2 days old): 7m9s
>> svn update -r21862 (from r21485, 3 weeks old): 1h12m
>> svn update -r21888 (from r20458, 2.5 months old): 2h57m
>>
>
> How often do you do such operations ?
I do them to get fresh updates, to commit to both brunches, and sometimes to find the
version in which a bug is introduced. Last month, because of xulrunner and docs in trunk,
my updates took ~8 hours.
Fresh updates - sure, but that does not take long if you do it often.
Commit to both branches - don't you have two copies or do you really do svn switch
between them ?
xulrunner updates happens very rare so I'll assume it only caused problems because we
did a big update ?
Docs - well, then just exclude it.
The solution for this is to get our Tycho build running and have a snapshot (p2)
repository setup so you only have to get
the module(s) you are interested in changing as source and get rest as binary
dependencies.
> Those times doesn't sound like something excluding
documentation will fix, nor
> do they look extremely slow for a large codebase ?
By deleting all docs from trunk and moving xulrunner to a different directory, the time
of 21485 to 21862 updating has reduced to 0h29m (better than 2x improvement).
because changes happend in that area, right - if those changes happened in VPE or JSF
would you also want to remove that ? :)
But yeah, if splitting the build up doesn't help in this area moving docs might be the
best option, but not right now.
>> Under Linux short updates take 1-2min, and there is no
difference for long ones.
>
> So the problem is windows ?
I mean that long updates take approximately the same time on both systems. Thus no,
windows is not the problem.
ok.
/max