7:52 a.m.
(redirecting to the right list )
-max
On May 6, 2010, at 10:13, Andersen Max wrote:
On May 5, 2010, at 10:26, Yahor Radtsevich wrote:
> Hi Max,
>
> 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 ?
Those times doesn't sound like something excluding documentation will fix, nor
do they look extremely slow for a large codebase ?
> Under Linux short updates take 1-2min, and there is no difference for long ones.
So the problem is windows ?
/max
>
>
> On Tue, May 4, 2010 at 1:38 PM, Andersen Max <max.andersen(a)redhat.com> wrote:
> Thanks for the tip...but How loong are those updates ?
>
> doing an svn update for me takes less than 1 minute, sometimes 1.5 minute.
>
> Rob (who is in China) just did it in 90 seconds from a coffee shop.
>
> What is the time for you ?
>
> /max
>
> On May 4, 2010, at 11:01, Yahor Radtsevich wrote:
>
>> Hi All,
>>
>> If you, like me, are annoyed by looooong time of trunk updates, there is a SVN
feature to skip directories you do not use. This feature is called 'Sparse
Directories'.
>>
>> For example, to delete directory 'documentation' from your local copy of
trunk permanently, use the following command:
>> svn update --set-depth empty documentation
>> After this command, the documentation directory will be skipped during further
updates and switches. (To restore it back, use --set-depth infinity).
>>
>> Windows users may use the following batch-script to delete all documentation and
*\docs directories at once (just save as deletedocs.bat and run from trunk directory):
>> @echo DELETING OF documentation...
>> svn update --set-depth empty documentation
>> @echo DELETING OF *\docs:
>> @FOR /f %%d IN ('dir /b /a:d') DO (
>> @IF EXIST %%d\docs\.svn (
>> @echo DELETING OF %%d\docs...
>> svn update --set-depth empty %%d\docs
>> )
>> )
>>
>>
>> Best Regards,
>> Yahor Radtsevich
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
10:30 a.m.
New subject: A tip: How to speed up SVN updates
On Thu, May 6, 2010 at 3:52 PM, Andersen Max <max.andersen(a)redhat.com>wrote:
(redirecting to the right list )
-max
On May 6, 2010, at 10:13, Andersen Max wrote:
>
> On May 5, 2010, at 10:26, Yahor Radtsevich wrote:
>
>> Hi Max,
>>
>> 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.
> 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).
>
>> 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.
>
> /max
>>
>>
>> On Tue, May 4, 2010 at 1:38 PM, Andersen Max <max.andersen(a)redhat.com>
wrote:
>> Thanks for the tip...but How loong are those updates ?
>>
>> doing an svn update for me takes less than 1 minute, sometimes 1.5
minute.
>>
>> Rob (who is in China) just did it in 90 seconds from a coffee shop.
>>
>> What is the time for you ?
>>
>> /max
>>
>> On May 4, 2010, at 11:01, Yahor Radtsevich wrote:
>>
>>> Hi All,
>>>
>>> If you, like me, are annoyed by looooong time of trunk updates, there
is a SVN feature to skip directories you do not use. This feature is called
'Sparse Directories'.
>>>
>>> For example, to delete directory 'documentation' from your local
copy
of trunk permanently, use the following command:
>>> svn update --set-depth empty documentation
>>> After this command, the documentation directory will be skipped during
further updates and switches. (To restore it back, use --set-depth
infinity).
>>>
>>> Windows users may use the following batch-script to delete all
documentation and *\docs directories at once (just save as deletedocs.bat
and run from trunk directory):
>>> @echo DELETING OF documentation...
>>> svn update --set-depth empty documentation
>>> @echo DELETING OF *\docs:
>>> @FOR /f %%d IN ('dir /b /a:d') DO (
>>> @IF EXIST %%d\docs\.svn (
>>> @echo DELETING OF %%d\docs...
>>> svn update --set-depth empty %%d\docs
>>> )
>>> )
>>>
>>>
>>> Best Regards,
>>> Yahor Radtsevich
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>
>
1:30 a.m.
New subject: A tip: How to speed up SVN updates
>> 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
4:10 a.m.
New subject: A tip: How to speed up SVN updates
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
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
2:12 a.m.
New subject: A tip: How to speed up SVN 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.
that all depends on the amount of deltas which will always vary over time.
> > 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.
And docs are unnecessary ? They need to be built and maintained too...not just by doc team
;)
But yeah, if splitting the build up doesn't help in this area
moving docs might be the best option, but not right now.
/max
5333
days inactive
5339
days old
jbosstools-dev@lists.jboss.org
4 comments
2 participants
participants (2)
-
Andersen Max -
Yahor Radtsevich