brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <>
Subject Big files in repo
Date Thu, 22 Jan 2015 14:36:28 GMT
Having cloned the brooklyn repo a number of times over the last days I was curious why it's
so big. As expected there are a number of binary files, probably unmodified since their first
commit, having been deleted a long time ago polluting the history.
Here's a summary of the largest offenders:

All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack
size   pack   SHA                                       location
57722  57718  01760133fa9dedc811762019a2aaa691bbe61988  monterey-example/src/main/resources/booking-mvc.war
23917  23905  d0b52371d4ba447ee9b0f882854b4b5d4d39147f  monterey-example/src/main/resources/jboss-booking.war
23915  23903  4f6c7f01e0f49c5e3574d648bcab991f7cab5236  monterey-example/src/main/resources/monterey-booking-as7.war
21737  20984  ab9740889e11e06df060595684c2bd803c1baac1  examples/simple-nosql-cluster/src/main/resources/cumulusrdf-0.6.1-pre.jar
20988  20993  04a0a6fd94873543cfec769b5a272bbe36f0a914  examples/simple-nosql-cluster/src/main/resources/cumulusrdf.war
12124  12119  7ccd0ef45879c78941575d47a8521eef49b0b704  sandbox/examples/src/main/resources/swf-booking-mvc.war
7642   7063   0249fd11430b461f918e2b95adb52425caf81230  gemfire/lib/gemfire-
7217   7219   9d384383e5542b04ca2b6332aedba92bc92bc5bb  examples/simple-nosql-cluster/src/main/resources/cumulusrdf.war
2431   2428   5d7d1216a4276d82c3fabdfa25852e527e1bf78e  monterey-example/src/main/resources/booking-mvc.war
2430   2427   9fc9f74223ed9704e91810d5dd9fe79d41ff4b84  com.cloudsoftcorp.monterey.brooklyn/src/main/resources/booking-mvc.war

The only sane way to delete them without losing the history is to rewrite it with the big-file-commits
excluded. This has the downside that any PRs or cloned repositories will need manual intervention
after the changes.

I think it's worth the effort of removing them, having in mind the benefit of shrinking the
repo to a few MBs in long run. There's never a "right" moment to do such a change, but the
more it is delayed, the worse it becomes. So what are the thoughts of the community?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message