Hi Armin, U branches/alg/install/ext_sources/48470d662650c3c074e1c3fabbc67bbd-README_source-9.0.0.7-bj.txt 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. Regards, Dave 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] - >> http://svn.apache.org/viewvc?view=revision&sortby=rev&sortdir=down&revision= >> 1291394 >> > > Sincerely, > Armin > -- > ALG >
