openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: ooo large commit breaks mirror sync !!
Date Tue, 21 Feb 2012 17:46:15 GMT
Hi Armin,

 U   branches/alg/install/ext_sources/48470d662650c3c074e1c3fabbc67bbd-README_source-
 U   branches/alg/install/ext_sources/3b179ed18f65c43141528aa6d2440db4-serf-1.0.0.tar.bz2
 U   branches/alg/install/ext_sources/2c9b0f83ed5890af02c0df1c1776f39b-commons-httpclient-3.1-src.tar.gz
 U   branches/alg/install/ext_sources/48a9f787f43a09c0a9b7b00cd1fddbbf-hyphen-2.7.1.tar.gz
 U   branches/alg/install/ext_sources/bc702168a2af16869201dbe91e46ae48-LICENSE_Python-2.6.1
<snipping a bunch of redundant external source tarballs.>
 U   branches/alg/install/ext_sources/c441926f3a552ed3e5b274b62e86af16-STLport-4.0.tar.gz

Is it necessary to have all these external source tarballs in the branch? These files are
kept outside of trunk for a reason - to avoid sledgehammers on changes.

Consider using an svn tag on ext_source tarballs in your builds.


On Feb 21, 2012, at 3:11 AM, Armin Le Grand wrote:

> 	Hi Gavin,
> On 21.02.2012 00:21, Gavin McDonald wrote:
>> If anyone wants to do large commits like below link shows [1] (over 8000
>> paths changed and lots of zips and tar files.)
>> PLEASE notify infra first and schedule it for a WEEKEND.
> Sorry for that. All I did was updating a branch to current trunk. I was also surprised
that in that one week I wanted to get updates for sooo many files were touched, obviously
mainly flag changes.
> If updating a simple work branch can lead to this, something is not optimal and we should
think about it. It's not really an alternative when working with svn on a simple branch (where
only single files were changed) to wait until the weekend and to notify someone to continue
working, esp. when you want to use that branch to get the code to different build machines
on various OSes or various colleagues.
> We have svn branches as mechanism for that, I do not want to go back, create diffs and
sync repos on different machines per hand, this cannot be the solution, IMHO.
> I know - when looking at it now - technically I could have extracted a diff from my branch,
throw the branch away, create a new one from trunk and apply the diff. But this would have
required to know aforehand how many changes were done and that the commit would be extreme.
It's also not a good solution when you are committed to a project which works with a code
versioning system.
> Please point me to a solution which would be compliant with svn usage and infra and I'll
surely use it next time.
> From my POV it also shows that the mechanism to update svn branches is not optimal; all
those binary files which were committed and thus transferred again were already on the trunk,
so technically it may be time to think about a more effective way to update branches with
svn. Creating a branch does a 'cheap copy' (CopyOnWrite - COW), so I would have expected that
updating would somehow try to stay with this and not transfer all files again. Maybe it would
be possible (in the commit step of updating branches) to send a checksum of a file first,
see if it's the same as on trunk and add it as COW-copy...
>> People have been struggling to commit to the EU mirror since this large
>> commit was started 5 hours ago.
>> Thanks
>> Gav...
>> [1] -
>> 1291394
> Sincerely,
> 	Armin
> --

View raw message