[jbosstools-dev] A tip: How to speed up SVN updates

[Yahor Radtsevich]

On Fri, May 7, 2010 at 9:30 AM, Andersen Max <max.andersen at redhat.com>wrote:

> > >> 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.
>
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 ?
>
Right.

>
> 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 ? :)
>
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20100507/480607b0/attachment-0001.html