<br><br><div class="gmail_quote">On Fri, May 7, 2010 at 9:30 AM, Andersen Max <span dir="ltr"><<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> >> 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:<br>
> >> svn update -r21899 (from r21862, 2 days old): 7m9s<br>
> >> svn update -r21862 (from r21485, 3 weeks old): 1h12m<br>
> >> svn update -r21888 (from r20458, 2.5 months old): 2h57m<br>
> >><br>
> ><br>
> > How often do you do such operations ?<br>
> 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.<br>
><br>
<br>
</div>Fresh updates - sure, but that does not take long if you do it often.<br></blockquote><div>Big commits/movings always lead to long updates.<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Commit to both branches - don't you have two copies or do you really do svn switch between them ?<br></blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
xulrunner updates happens very rare so I'll assume it only caused problems because we did a big update ?<br></blockquote><div>Right.<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Docs - well, then just exclude it.<br>
<br>
The solution for this is to get our Tycho build running and have a snapshot (p2) repository setup so you only have to get<br>
the module(s) you are interested in changing as source and get rest as binary dependencies.<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> > Those times doesn't sound like something excluding documentation will fix, nor<br>
> > do they look extremely slow for a large codebase ?<br>
> 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).<br>
<br>
</div>because changes happend in that area, right - if those changes happened in VPE or JSF would you also want to remove that ? :)<br></blockquote><div>The idea is to exclude all _unnecessary_ folders from local copy :) It is simple and it works.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
But yeah, if splitting the build up doesn't help in this area moving docs might be the best option, but not right now.<br>
<div class="im"><br>
<br>
> >> Under Linux short updates take 1-2min, and there is no difference for long ones.<br>
> ><br>
> > So the problem is windows ?<br>
> I mean that long updates take approximately the same time on both systems. Thus no, windows is not the problem.<br>
<br>
</div>ok.<br>
<font color="#888888"><br>
/max</font></blockquote></div><br>