Pull Daily Builds using GIT!

Solar2D Daily Builds and Public Releases
#1

Hi there…

I personally want to use the daily builds often but downloading it as dmg and installig it every day (or work day) is boring me pretty much.

As I am already using GIT to keep my CoronaSDK Application Folder “adjustable” by “commiting” the files in a new daily.

That way I can “git checkout 2012.783” or “git checkout stable” to swap between different daily CoronaSDK Builds to test if bugs are my or ansca’s fault. Esp. if it is top notch stuff.

I also get a nice “changes” log that way (which can help a lot if you try to stay with current sdk extensions)

But what about Ansca giving us a GIT Repository for the daily builds to clone from?

That way you could just “git pull” to have the daily build and ansca could even provide the changes in the git message!

Ansca even could make the SDK “update” itself using git in the background by having a little script which does nothing than calling git for the installation folder!

So what you think? [import]uid: 6928 topic_id: 25504 reply_id: 325504[/import]

#2

I think the .dmg files are quick, easy to use and more welcoming for beginners.

Matt
W2MD [import]uid: 10211 topic_id: 25504 reply_id: 103101[/import]

#3

I don’t understand your post Matt?

.dmg files would be the same as they are!

It is just me that wants a “10 seconds” hassle free update with easy rollback option for the daily builds :slight_smile:

That was not asking for anything that beginners would _need_ to use.

But I even doubt that beginners are the usual target audience for daily builds of beta-software anyway.

Still “Semi Self updating” with a git background could be even more “Welcome” and “Beginner” friendly than downloading and managing dmg files by yourself.

A site like github.com (alone) has more than 5 million git repositories… Can’t be to hard of a technology and is even included with OS X. [import]uid: 6928 topic_id: 25504 reply_id: 103109[/import]

#4

Git is not optimized to handle binaries. I expect the repository will grow by the size of each new binary. Let’s assume for simplicity that the binary is 100MB. In 10 days, the Git repo will be 1GB. It will quickly grow to the point where it will be too big for anybody to clone.

(I know Corona Simulator.app won’t be quite this bad since Git will track the individual binary files that make it up separately and those don’t always change. But I would expect it would still grow out of control very quickly.)

[import]uid: 7563 topic_id: 25504 reply_id: 103154[/import]

#5

By the way, on Mac, it is possible to have multiple Corona versions lying around. I keep them in separate folders labeled by build number.

[import]uid: 7563 topic_id: 25504 reply_id: 103157[/import]

#6

Well nice guess but thats not true!

GIT “inside” makes no assumption about the content at all. GIT is not using “diffs” like most Source Revision Control Software does. Actually it works pretty efficient with binaries (even with its standard configuration).

3 SDKs (Stable + the last 2 dailys) add up to 61 MB total in my .git folder (the repository). Which is less than all the files for one SDK.

GIT even can create patch files for and including binaries… you coult even put your whole “/User/bla” folder under GIT and it would work pretty well.

I even use GIT to revision huge (>1 GB) binaries of mysql databases which works well on the right hardware…

Keeping multiple Versions in the filesystem works but has some limits… like having Spotlight finding all of them… or having much larger footprints for backups and so on.

But the biggest drawback is I have to download some 70 MB for changing 5 files “daily” and move them around without knowing what has changed “inside”.

Even if it would “grow” a lot you could just trim it back by pruning older revisions like the once form month ago… [import]uid: 6928 topic_id: 25504 reply_id: 103160[/import]

#7

Not that we’re going to do this (you people can figure this out yourself…git is distributed), but how big is a repo with 30 different revisions? Try two different time periods in case it fluctuates.

How is ‘pruning’ done (and without nasty side-effects like rehashing all the commit ids)? (Git proper at least hates that as far as I know.)

[import]uid: 7563 topic_id: 25504 reply_id: 103163[/import]

#8

Well I may tell you in about 30 days… Not going to do the work I want to avoid by making this feature request to prove that the request is valid… well maybe I do tomorrow :slight_smile:

Pruning would be on the user side and consolidate multiple changesets into one.

It is as simple as using “git rebase -i” and deleting the stuff you won’t need anymore.

Doing some “git gc” afterwards to regain some space too.

And yes it is “bad” to do if users base their work on your repository… but they don’t they just pull a copy of it :slight_smile: [import]uid: 6928 topic_id: 25504 reply_id: 103165[/import]

#9

Well…

I d/l all SDKs from the daily build site.

Made a folder … inited it as git repo …

Extracted the contents of each single dmg in that folder…

Did “git add -u .” inside … then “git commit -m xxx”

End result without any modification or even git gc is 78M for the repository.

For the curious people I added 2 screenshots which prove what I just proved for your education…

Resulting Folder: http://d.pr/i/FJSG
Git Revision Log: http://d.pr/i/691N

I hope that makes you re-evaluate my original feature request… [import]uid: 6928 topic_id: 25504 reply_id: 103173[/import]

#10

All I’m saying is if it ain’t broke, then don’t fix it.

Matt
W2MD [import]uid: 10211 topic_id: 25504 reply_id: 103174[/import]

#11

After that I used “git rebase -i” and squashed all revisions between 700 and 780 into a single commit… the .git got up to 79M … then I called “git gc”… and the .git is 63M afterwards…

@Matt I am not talking about replacing something with something else… nor changing anything which is existing. I again think you made a senseless comment. No biggies but thats just “meh”… [import]uid: 6928 topic_id: 25504 reply_id: 103181[/import]

#12

(system double posted my article - did that 2 years ago already needs a fix because its broken – just kidding) [import]uid: 6928 topic_id: 25504 reply_id: 103182[/import]

#13

meh [import]uid: 10211 topic_id: 25504 reply_id: 103188[/import]