possible to stop including build objects in the repo?

[ph1l]

I wonder, as I sit waiting to clone this repo, is it possible to automate a build system so you don't need to check in the build objects for every version?

$ du -sh freeboard-server
357M    freeboard-server

That's pretty big, and only growing...

[rob42]

yes this is beocoming a problem.

It began with a way to get easy installs for non-tech users. The old method of scripts and deploying jars etc was too fragile, especially if updates were needed. The all-in-git method is an abomination for disk space but works really well for users, just git pull and you are done.

A work-around is to use git --depth which limits history. I try not to commit the main jar file unless its needed for average users (eg no intermediate test builds). But its easy to do by accident.

In the signalk-java project Ive started using jitpack.io to create the jar files and serve them. Its easier than maven as you dont need to deploy, just tag the code.

The signalk-java project is better suited to this as it has html and java fully separated, so you can clone the html project, and ge the jar from jitpack (via maven), whereas freeboard-server uses the zk toolkit, which means its all together. This makes it complex to use jitpack.io, which mainly serves jars etc.

Its also possible to export/delete/import the project to remove the old jars, but that will break currently cloned repos, they will need to be re-cloned.

Preferences?

[rob42]

Hmm - maybe the answer is freeboard-2, and new repo with better build method aka jitpack?
That wont break freeboard, and users can migrate as preferred?

[ph1l]

I guess, if the build system were updated and build objects were no longer being committed to the repo:

• It wouldn't grow as fast in the future, and
• You could decide how to proceed then

The current design does make it easy to update. Supporting a new installation / update procedure and migration path will be complex.

bah.. sounds like a lot of work...

[rob42]

yes - it would be great if git had a facility to zero-length old binaries but I guess that breaks the basic reason for having git :-(
Or a way to 'forget' history before a given commit maybe. Wonder if a shallow cloned repo can be made , then disconnected, and used to replace 'master'...

[rob42]

Seems git --orphan can do a lot of this.
http://stackoverflow.com/questions/5724522/creating-github-repository-with-only-a-subset-of-a-local-repositorys-history/5724782#5724782
I will investigate...

[rob42]

Running git gc in the root dir brought mine down to 196Mb. Have to find a way to do that on github.