On Fri, May 7, 2010 at 9:30 AM, Andersen Max <max.andersen(a)redhat.com>wrote:
> >> Regular svn updates (with short delta) are acceptable
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.
Big commits/movings always lead to long updates.
Commit to both branches - don't you have two copies or do you really do svn
switch between them ?
I have them now, but remembering old days it was faster to do svn switches,
than to maintain a copy. And it does not solve the problem with rolling back
to previous revisions.
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
> > Those times doesn't sound like something excluding
> > 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 ? :)
The idea is to exclude all _unnecessary_ folders from local copy :) It is
simple and it works.
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
> > 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.