incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: ooo large commit breaks mirror sync !!
Date Tue, 21 Feb 2012 11:11:45 GMT
	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


View raw message