Edit your code in the cloud with bitbucket(blog.bitbucket.org)
blog.bitbucket.org
Edit your code in the cloud with bitbucket
http://blog.bitbucket.org/2013/05/14/edit-your-code-in-the-cloud-with-bitbucket/
10 comments
I don't find such feature very useful. Without a way to execute code or run tests it seems too easy to break something.
It is nice at least for editing .md files to update readme/instructions/etc.
Sometimes I want to do a quick edit without having to cd directory, make sure I'm up to date, edit file, add/commit/push just for a md file in the repo
Sometimes I want to do a quick edit without having to cd directory, make sure I'm up to date, edit file, add/commit/push just for a md file in the repo
I've used GitHub's online edit for this very reason, but mostly for other people's repos. If I'm reading a README or docs to figure out if I like a library or want to use it I'll submit pull requests from my browser to fix typos or unclear/incorrect sections.
It wasn't a critical update, but one that wouldn't have happened if I had to fork/clone/push/pull-request it.
It wasn't a critical update, but one that wouldn't have happened if I had to fork/clone/push/pull-request it.
If using the web interface feels better for something like that, it shows just how bad the alternative is. It's not nice when something like source control feels like it gets in the way, but it could be mitigated by having better/easier client tools.
I totally get why you'd want to do that.
I totally get why you'd want to do that.
So you are saying git gets in the way? I'm curious about why that is the case.
I didn't know if they used git or hg, and I wasn't necessarily having a go at either. The poster obviously thought that there was less friction to an online edit, so you have to ask yourself why that is?
Perhaps they don't like fiddling about on the command line, their IDE is too klunky, file managment is a pain, their version control interface is convulted, or they are not sitting at their computer with their codebase - who knows!
Either way they appear to find it easier that way.
Perhaps they don't like fiddling about on the command line, their IDE is too klunky, file managment is a pain, their version control interface is convulted, or they are not sitting at their computer with their codebase - who knows!
Either way they appear to find it easier that way.
Or maybe the issue tracking system is a web tool that links to the file in the repository and you could fix it with a click to edit instead of pull,open file,fix,commit,push.
Documentation or fixes to comments in code is an obvious usecase for online edits cross-language.
If you'd really rather do the pull,open,fix,commit,push i would argue that you are too stuck in your own ways.
Documentation or fixes to comments in code is an obvious usecase for online edits cross-language.
If you'd really rather do the pull,open,fix,commit,push i would argue that you are too stuck in your own ways.
Uh...you have to clone a whole project to make a simple little edit?
Exactly.
It's only a useless feature, if you think people who don't think a service by BitBucket will ever be used by people unfamiliar with git and programming.
I for one am very pleased with the opportunity for crowd-sourcing fixes and improvements to open-source websites and projects - especially for people whose interest in them is not grounded in the programming aspect.
It's only a useless feature, if you think people who don't think a service by BitBucket will ever be used by people unfamiliar with git and programming.
I for one am very pleased with the opportunity for crowd-sourcing fixes and improvements to open-source websites and projects - especially for people whose interest in them is not grounded in the programming aspect.
One major reason for this feature is that it's used to edit the wikis. Wikis are git projects in bitbucket so you can check them out and edit them locally, or edit them in bitbucket. For the less technical users collaborating on a project, I'd say that this feature is a big win.
I have a CI server which polls for the latest. It compiles and executes tests. If something fails I get notified (e-mail, etc).
As long as you have something like this in place, it doesn't matter how the change gets committed to the repository.
As long as you have something like this in place, it doesn't matter how the change gets committed to the repository.
It's just a start, I'm sure it wouldn't be too difficult to add these features in future for popular languages if there is demand for it. It's pretty exciting IMHO.
Executing code would actually be very difficult. They would need to configure an isolated VM for each run (for security) and somehow figure out a generic way to install/configure dependencies.
For many languages (especially interpreted ones) you could just use a dumbed down interpreter with crippled libraries.
It's fairly common actually, like the PHPs running in shared environements.
Many programming language's websites let you try running some code from the browser, without having to install anything as well, see for instance http://dlang.org/ (amongst many others).
I'm not sure it would be very useful (to me at least, but I mostly write C) but it's definitely not rocket science.
It's fairly common actually, like the PHPs running in shared environements.
Many programming language's websites let you try running some code from the browser, without having to install anything as well, see for instance http://dlang.org/ (amongst many others).
I'm not sure it would be very useful (to me at least, but I mostly write C) but it's definitely not rocket science.
IF you had it hooked up to something like heroku, then it could be pretty useful, not the best option, but still useful sometimes.
bitbucket can ping a web hook on every commit. set up a hook that pulls the code to your test server and runs your test suite.
Deploy to staging or test environment.
This is great if you are stuck somewhere needing to change something. I really like bitbucket, about the only thing I miss on their site is a "gist" like functionality.
I want them to open an API for this, maybe I want to make edits my own way, or write a tool for others?
Seems like a good alternative for online pairing or even interviews!
I was hoping they'd leapfrog GitHub and allow you to stage actual commits and use something like CodeMirror to edit.
Isn't that exactly what they did?
I guess I always expect UI chrome around CodeMirror, but yeah, it obviously says CodeMirror right there, DOH, I missed the color syntax highliting when I skimmed through. I still don't see how to do multifile commits all from the web-ui which is what I meant to reference. I can do one-off files on GitHub but they're a commit a piece.
Both GitHub and BitBucket are really close to letting me do significant editting of code from my browser which is still very useful for me. There are tons of times I'd love to be able to fire up GitHub and hack on some files without having to actually commit to persist changes. But then again, maybe I'm projecting feature creep on what is ultimately a VCS.
Both GitHub and BitBucket are really close to letting me do significant editting of code from my browser which is still very useful for me. There are tons of times I'd love to be able to fire up GitHub and hack on some files without having to actually commit to persist changes. But then again, maybe I'm projecting feature creep on what is ultimately a VCS.
I still find Bitbucket less usable than Github. The price is right, I suppose.
I fail to understand why I shouldn't use my favorite editor, I'd call it a non-feature (useless, not available from the competion because it is useless).
I know that I've used GitHub's online editor a few times in situations where I see a quick typo I need to fix or want to make a one line change without the hassle of opening up the right directory, pulling the latest code, opening up an editor, etc etc.
Sorry to hear that your IDE totally sucks - scnr.
It just depends on how you approach it, since I prefer to work local and upstream revisions with change notes, the main reason for revision control.
Given the featureset of github, it makes somehow sense, it just contradicts revision control to work directly in the repository.
It just depends on how you approach it, since I prefer to work local and upstream revisions with change notes, the main reason for revision control.
Given the featureset of github, it makes somehow sense, it just contradicts revision control to work directly in the repository.
How does it contradict revision control? You can make a change and add a commit message all in 1 fell swoop. Then the next time you `git pull` that commit will be pulled down, just like any other.
As others have said, it's amazingly useful for quick and small changes. I don't see how that means someone's IDE sucks. I work on many projects and don't have all of them open in my IDE with the latest code always on my machine. This totally beats opening that project, running a `git pull` (which may take a while on an active project which I haven't visited in a bit), making the change, then committing and pushing.
On top of this, it's useful for non-technical people using these tools. Not everyone can move around through multiple repositories and pull down updates as easily as you or I. However, now they can easily help keep documentation up to date without leaving their browser.
As others have said, it's amazingly useful for quick and small changes. I don't see how that means someone's IDE sucks. I work on many projects and don't have all of them open in my IDE with the latest code always on my machine. This totally beats opening that project, running a `git pull` (which may take a while on an active project which I haven't visited in a bit), making the change, then committing and pushing.
On top of this, it's useful for non-technical people using these tools. Not everyone can move around through multiple repositories and pull down updates as easily as you or I. However, now they can easily help keep documentation up to date without leaving their browser.
It makes sense if you are on the same social coding platform.
It's not always for projects that you're actively working on--I've done it a lot for projects that I have never previously touched and wouldn't otherwise go to the trouble of cloning just for a small tweak, like a random open source project with a typo somewhere.
I don't think it's at all related to the editor I use (I use vim anyway so I don't think that's the issue).
Maybe it's worth considering that others prefer different workflows than you or have different use cases?
I don't think it's at all related to the editor I use (I use vim anyway so I don't think that's the issue).
Maybe it's worth considering that others prefer different workflows than you or have different use cases?
I don't believe we'll ever see developers tossing out their IDEs to edit things through the web, but this as an API this is a huge open ended solution towards automated testing.
You are doing some clojure work, you commit it, the unit tests run and fail. Clojure can tell you exactly what function failed with what data and it could commit a file for you to execute in your repl.
Using the ability to edit/create files through a webservice means the CI server running the Clojure tests could dynamically add or edit files showing the real failure over some pretty-print error message. You could check into the branch and open up user_104_error.clj and see the data that caused the problem.
When you solve the problem the CI server could automatically delete these files from the git repository, or maybe keep them around just to keep testing them.
Automated code modification into the version control system really could be interesting new ground in continuous integration and testing.
That and just last week I committed a file with the javascript url hardcoded to http://localhost/sit/js/api.js and wanted to change that back before anyone noticed.
You are doing some clojure work, you commit it, the unit tests run and fail. Clojure can tell you exactly what function failed with what data and it could commit a file for you to execute in your repl.
Using the ability to edit/create files through a webservice means the CI server running the Clojure tests could dynamically add or edit files showing the real failure over some pretty-print error message. You could check into the branch and open up user_104_error.clj and see the data that caused the problem.
When you solve the problem the CI server could automatically delete these files from the git repository, or maybe keep them around just to keep testing them.
Automated code modification into the version control system really could be interesting new ground in continuous integration and testing.
That and just last week I committed a file with the javascript url hardcoded to http://localhost/sit/js/api.js and wanted to change that back before anyone noticed.
Thanks for confirming what I had in mind.
When I want to quickly update a readme file or comment, I find it convenient to be able to do it directly in Github (and now Bitbucket).
Please. make. new. accounts. read-only.
https://bitbucket.org/site/master/issue/2323/create-a-way-to...