Version Control is HERE! (BETA)

I used http.get to write a small GitHub client for codea

I does require you to jailbreak codea out of its LuaSandbox.lua (ie comment out everything in that file). Also note that it sends the GitHub password in clear text so I’d recommend changing your password before using. But otherwise it’s awesome!

What it supports so far:

  • upload codea projects to github
  • diffs

Well that’s it really, but that’s already pretty useful. What it doesn’t support but it should/it will sometime:

  • setup empty github repos. I could not figure out how to use the github API to do this, frustrating…So it means that to upload a project you first need to setup the repo and initialize it
  • download github repos to codea
  • commit messages
  • revert local codea version to previous github versions
  • diffs to previous versions
  • commit only a subset of files
  • delete files that were deleted local from the github repo
  • etc,etc

Anyway, let me know what you think. The project is here:

I hope this is the last time I send a .codea project around (well maybe once more, when I create the “download repo” function)

And feel free to add to it. The repo is here

What do I think?

This causes more harm than good.

It does nothing we need version control on the ipad to solve, and it flaunts apple’s rules. I don’t give a crap if you do that and keep it to yourself - it’s when you share this sort of thing that you endanger the community.

The only upside is it takes modifying the Codea files, so very few people will do it.

@Bortels, I’m sharing on the beta forums. I’m talking to @Simeon about sharing more widely.

It does start to solve version control by the way. It’s just a start.

I do find the idea that sharing something endangers the community deeply flawed. If the long term success of codea depends on not a single user taking http.get and using it to share code, well then http.get is doomed (or more likely codea will have to put some restrictions around it). I’m glad to keep it to myself if TLL wants me to because I feel like I owe one to those guys, but if not me, then some random guy on the street will do it.

Anyway it’s been discussed at length elsewhere.

The long term success of codea depends on it’s users seeing desired features added, not removed.

The most likely way to get http.get pulled entirely is to rub it in apple’s face. This does that. If and when apple wants to allow code sharing without cut and paste, they can allow it, and TLL can alter Codea to take advantage of that.

The beta forums are NOT private, by a longshot - anyone searching for http.get or version or just your name or mine will have this post come up in the results. Not an unfounded fear - it’s happened.

Is this whole situation messed up? Yes. Very much so. But it’s reality. And I don’t think this is an unfounded concern either - We had .codea files (you and I still do), and Apple took em. I don’t see any evidence they won’t turn around and do the same again. Unlike the other Lua packages with sockets, Codea has a track record of supporting the creation of apps that are of quality comparable to regular app store apps.

Those who do not learn from history are doomed to repeat it.

I’m not concerned about random idiots playing with using http.get to share code - I’m concerned about someone with a track record of doing good code making something people actually use, instead of the feature (which I do desire) being added by TLL and properly approved by apple.

I’m not sure what to tell you man. Maybe it makes you feel better that you need to jailbreak codea to use this, so not so different that your jailbroken ipad? I think in the end we just came to different conclusions on this.

But i’m glad to defer to @Simeon, this being codea’s forums, though I have not got a negative message on this issue yet.

If you have comments on github client itself please let know

I’m not sure what Apple will think about this.

It requires significant effort in order to use — by installing Rui’s github client you are automatically a pretty serious developer and know what you are doing. I mentioned to Rui that if he wants to share this I’d like him to stress that it is not default Codea functionality and requires modification of the App in order to use.

Other than that I think it’s a spectacular project and could lead to some really interesting development. It’s something I wish we could put in ourselves, but our hands are tied in this situation.

The difference between this and a jailbroken ipad is there’s nothing Apple can do about the jailbroken ipad (or, presumably, they’re doing what they can). But for this, Apple has a very easy solution - poof, no Codea.

It just seems simple to me - if TLL can’t do something because Apple will yank Codea, and we’ve seen it happen in the past - then if the users do it, Apple will just yank it. They don’t need to differentiate between TLL writing code and the end-users - it’s no skin off their nose if they feel the need to pull and app or have TLL remove features.

More to the point, while what @ruilov is doing may “need” modifying the Codea files - the basic concept does not. We all know that http.get and loadstring are a potent combo. By displaying this to the world, we could well be forcing apple’s hand, and I just hope that the removal of loadstring() will be sufficient for them to leave http.get - I fear that won’t be the case.

Dunno - maybe I’m Chicken Littling, but I honestly don’t think the benefit of this sort of version control is worth the risk. If it wasn’t clearly against Apple’s policy, I’d be all for it. And I’m all for trying to work within channels to convince Apple to change policy. I don’t think this will work - what I see coming down the pipe is an app pull, and a big nerf, and all of the web-based goodness that we’re on the verge of going down the toilet. Ask yourself this - do you really think “oh, we didn’t do that, an end user did” is going to stop apple if they decide this isn’t in their best interests? And do you really think Apple’s first response as a fix suggestion won’t be to remove http.get?

There is some level of differentiation at Apple between the user doing something, and the app doing something. When I spoke with an app reviewer about Codea he said that copying and pasting code violates their policy. But they don’t do anything about that.

I think to Apple the app needs to be reviewed with its entire functionality laid bare. You can’t introduce any new features after the review process is done. They saw the .codea system as a mechanism that the app itself was using to introduce new features after review. I see Rui’s git client on the other side of that line — so much work is necessary to use it (but it pays off once you do) — that it’s a very user-motivated way of getting code.

Perhaps I misread Apple’s intention. But my understanding is that they want the review process to examine all functionality of the app that is available to the user (and not to prevent competing app stores, as other people have said, I don’t think they care about that). Obviously that’s not possible with coding apps. So what they seem to be doing is making sure that the user is fully aware of what they are doing by forcing them to copy and paste or manually type the code.

@Bortels, http.get allows you to download and upload code. Period. Is apple ok with that? I don’t know. They approved this feature after extended review so I think it’s likely that they are in fact ok with it.

They also didn’t pull codea before http.get existed even though you could already share code without manual copy/paste of text (it’s not very hard - connect a usb cable to your PC and pronto, you can share code).

Now if you’re right and Apple is actually not ok with http.get and just didn’t realize what you could do with it during their review (I don’t think that’s the case, but assuming it is) then it won’t be long before they pull http.get, whatever you and I or @Simeon do. You give me too much credit - an entrepreneurial 12 yo (Zoyt?) could set up his little web appstore now. Maybe apple is thinking that it would be irrelevant for them. Or maybe they are ok with features that are not intended to share code even if they allow you to. Who knows what they’re thinking - all I know is they approved the feature.

Asking your users to play nice is not a stable equilibrium if all it takes is for one person to do what you don’t want, and there’s no way to prevent them from doing so. A system with a single point of failure is broken.

In that case I’d rather at least benefit from http.get while I can, and a github client is something I find truly useful. I will not develop a big project like cargo-bot in codea anymore before I don’t have version control. It’s just too hard to keep track of changes, and if I break the code it’s close to impossible to find out why.

And note that this has nothing to do with loadstring. Loadstring helps you execute code, but I’ll say again: http.get allows you to download and upload code. If I didn’t have loadstring I’d find another way to execute the code. Also the github cilent doesn’t use loadstring (heck, it doesn’t even download code…but it would be very easy to add a “play project from github” button)

Sorry for the long post. Now:

“… I honestly don’t think the benefit of this sort of version control is worth the risk”

Can you clarify? The github sort?

The off-iPad sort.

I think one of the really exciting parts of codea is native development - making things for the iPad on the iPad. Any scheme that involves something external to the iPad is less than desirable. In this particular case, I want to be able to dive in and make changes with confidence, knowing I can easily roll back to a functional state, and knowing I can easily compare the current state with a prior state, so I could produce a patch or diff. I can do this in a very rudimentary fashion by cloning a project - but that’s intrusive and without being able to compare locally, limited.

If I’m going to use github (or any other external sorurce), I’d be better off putting the code to transfer data to/from the iPad on that external source - its more powerful than codea in that it can manipulate codeas entire document structure, and it’s entirely unlikely to generate a negative response from apple. Apple forbids an app downloading and executing code - but they say nothing and have no control about an outside application pushing code to the iPad like iTunes does. What you run on your Mac or windows box is your business.

Come to think of it - an app (for win/mac) that combined iExplorer functionality (treating the iPad simply as mass storage) but that did version control would be totally kosher. Still not native, but accomplishing this same goal without the same risk.

Thats why I find this so abhorrent - its less functional and higher risk than just doing it right.

In the case of native version control, all on iPad, http.request would be irrelevant. If your code simply hacked native file I/o and copied/diffed projects, there’d be no real risk from apple. Indeed - I’ve called for local file I/o (within the apps documents directory) for just that reason.