> >> 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