for updated-infrequently-if-ever repos, github's pricing doesn't make a lot of sense. i have plenty of small, one-off repos i'd love to back up on github but it doesn't make sense for me to upgrade plans for them.
i just back up to multiple boxes, but i can understand why someone would want something centralized and specific.
I agree. My small company has many 1-2 week dev efforts that we'd like to have on GitHub but simply can't afford it. I've tried creating a "small project" repository and using different branches to host the different projects but am definitely not satisified. GitHub NEEDS a size-limited hosting plan.
One plan, one price seems like a good tagline, but what if a user needs more than 2GB? I guess you'll want to charge them more money for more space, and eventually will have more plans, or will charge per GB?
Btw, I like both the idea and execution. Good luck... :)
> Please note: While we do not guarantee our free services, we do want to build a long-term relationship with you. So, even if you sign up today for a free plan, and we discontinue that plan, we provide service for at least a year after you sign up. We will add and remove our Free offers to meet customer demand. Enjoy what we have posted today, and check back regularly for additional offerings!
The UI at Assembla is awkward to work with. I participated in a project that used Assembla, and I kept getting a flood of emails attached to tasks and revisions that I didn't want to follow.
A similar thing happened to me a few weeks ago when I was looking for a way to add more repositories to a project. Luckily I got an answer quickly on their support forum (and yes, it was there).
So yes, the UI and information hierarchy is lacking, but ultimately it can do a lot of things.
(For future reference, you can change the settings under Stream - Email Notifications).
Assembla is not really a GIT hosting, it's project management with repos. You can use tickets, wiki, internal forum, GIT/Mercurial/SVN repos and some build/deploy tools.
Admittedly some of their tools have small problems, but the team is responsive and improves it steadily.
I've used one of their paid programs for everything we do (must be about two years by now) and I would recommend it.
Assembla doesn't seem to have that social aspect like Github, but I find their combination of tickets, wiki, forum and repos more useful.
Maybe I'm not fully understanding this.. If I don't need the web interface and public code sharing, why would I use this verse getting a Linode instance and installing git there.
I know I don't need a web interface, at the same time I know people that loves and only uses the UI. Why not solving this specific problem and still making all other users happy?
> If I don't need the web interface and public code sharing, why would I use this verse getting a Linode instance and installing git there.
Private code sharing. You have to install something like gitolite (see my other comment) to do private code sharing with git on a VPS, or you'd have to create a system-level user for every person you want to share code with.
I just use bitbucket.org + Mercurial. More than enough for personal projects, or more, given that it's unlimited. The only limit is amount of users.
Switching to Hg was a bit of work, but I've actually learned to like it more than Git. Really though, it's the same kind of thing and I just use both. So I ended up at bitbucket for the same reasons OP built a new site.
Yes, same. I love all the effort they've put in to the web front end, but I'm not interested in their pay plans for private repos, which to me, is just too damn expensive. $12 a month for github repos with five collaborators and a piddly disc space limit, whereas I get five collabs and unlimited disk on bitbucket.
I use github for the network effects, but how does hg compare to git, speed-wise? I switched to git from bzr because bzr felt awesomely slow, although git is a real pain to use, even when you're familiar with it.
I understand that bzr and hg are almost identical, command-wise, but hg is about as fast as git, is that correct? What my workflow consists of is diffs/statuses/commits/pushes/pulls in projects with working trees of a few MB at most.
I don't have a large codebase to compare with honestly, plus since I'm working alone I don't generally have a lot of diffing/merging. But nothing I've done has had me saying "Boy that was slow," unlike something like Perforce, which is just slow. Always. Forever.
Hg is marginally slower, but not so you'd really notice. If you're crunching 20,000-line files on a regular basis it might be a concern. On repos of that size, I doubt you'd notice.
Git is a great tool for what it was built for and the group of users it was intended for--that is, rapid, tons-of-merges-and-pulls development on a gigantic codebase, for users for whom it is acceptable for man pages to serve as reminders rather than instructions. However, I appreciate the additional attention paid to tooling and user-friendliness in Mercurial-land that make it more pleasant for me to use.
The fact that all the tools can push to github make it easy to switch, which I just might do again. bzr was great, except for the fact that it just doesn't have that much traction...
I found bzr to be much as you described it - like hg, but slower. Nothing objectionable about the workflow (though the tools on Windows were very poor, I wasn't using Windows much at the time), just the perf on a particularly large chunk of code.
I configured a Git server on my EC2 micro-instance and just use that.
I was a paying GitHub customer until I decided that I spent too much money on online subscriptions. But when I'll pay for a Git hosting service again, I'm going back to GitHub, as I'm still a happy user of their free account. GitHub rocks.
Sure, competition is good, but I don't get what codeplane.com is offering, considering that configuring your own in-the-cloud repository is so easy on a VPS (that you're likely to have anyway and be left unused to its full potential otherwise).
Good for you for building this and then charging for it. There certainly is a place in the market for what you are doing and the price you are doing it.
I can say that's is pretty safe. Backup is not an issue: copies of all repositories are stored on S3, CloudFiles and Linode's backup solution. People can't access your repos, unless you allow them to.
You can set something like this up on any VPS with gitolite (https://github.com/sitaramc/gitolite) pretty easily. gitolite lets you set up very fine-grained per-user/repo/branch permissions, manage your users' SSH keys, and gives you nice clean git@git.you.com:repo-name access to your remotes.
I've done this for myself with a $48/year VPS from prgmr.com specifically because I needed more private repos than Github could offer (my setup instructions are here: https://gist.github.com/1035834).
Granted, if codeplane.com existed six months ago I probably wouldn't have bothered with gitolite. It appears they do nice things for you like backups.
I do this (also on prgmr) and manage backups with tarsnap+cron which with all my small repos costs nearly nothing even if I don't clean up old tarsnap archives.
Gitosis does not have as fine grained control as gitolite nor is it as well documented (config file errors are hard to debug), but it works well within its limitations. Both are now available as Debian/Ubuntu packages (gitolite was not when I started using gitosis). The other obvious difference is that gitolite is written in Perl and gitosis is written in Python. This should be a superficial difference, but sometimes the world isn't rational.
One other thing to point out is that Gitosis is abandonware (last commit was made in September of 2009).
Gitolite on the otherhand is under active development, the documentation is great, and the author is generally available on the #git channel as are many other active users of the software.
Gitolite is a fork of Gitosis that has been both improved and actively maintained. It even has a script to automate converting your old gitosis.conf to the new format.
Gitolite suffers from being well documented for an open source project yet still very hard to understand from a standing start - it's just not a very intuitive setup. I wrote a post on setting it up just to help me wrap my head around it.
Would there be a market for gitolite/gitosis hosting? Say, $1/mo for up to 1G of space, backed up, unlimited private/public repos, cli only, rudimentary web viewer for public repos via gitweb.
It's rather easy to set it up (as the comments here suggest), but seems like a lot of folks wouldn't want to go into trouble of learning about it and/or setting it all up properly, or don't have a server to put it on.
This is worth a try. Make sure you reach break even rapidly so you don't get stuck in burning money. If you already have a server available, then this is pure profit.
This is also a good opportunity to practice startup launching. Identify your target clients, where they are, what they are looking for, etc. Create a landing page with MVP offer description and subscription for availability notification. Check patio11's advices on optimizing the landing page. Then spread the word. The subscription feedback should give you a traction feedback. This should be enough to deduce the fee to reach break even as you launch. Assume only a percentage of subscribers will make the jump. If you can break even with only 10% subscribers adopting it, then things are sound.
What does the UI actually look like? Is it just the list of repositories? I'd be more likely to spend money if there was a tour, or an example project I could look at, or an annotated example session with the CLI tool.
While I'd understand this if the complaint was that gitorious is too complicated to setup and host, CodePlane doesn't seem to offer the rich web interface github and gitorious do. In the absence of that, how difficult is it to setup gitolite on a cheap VPS account? I mean, if you primarily use CLI interfaces anyway.
Need redundancy because those fly-by-night VPS providers disappear? Fine, pick up another VPS from lowendbox.com and rsync your git home directory. Done and done.
On a side note, you could consider all your repos on your primary machine your "backup," as with a relatively static IP from a cable or DSL account you can push and pull to your hearts delight from your home box. Not great for collab, but sometimes I feel like the D in DVCS gets forgotten about.
Github's pricing model really is a painpoint for little consulting shops. We drive next to no traffic and storage on there, but we do a few projects every quarter. Haven't quite outgrown our paid plan yet, but we will in a bit.
Just wish Github would revise their pricing to support peeps like us, I hate to use different interfaces. May choose to just archive things to codeplane until then, keeping things we are actively developing on github.
Try unfuddle, their hosting includes both svn and git ... doesn't have most of the thrills and spills of github but I find their pricing very reasonable.
I think CodePlane is very cool, but it seems to solve a different problem than the one advertised on the blog.
To save my repos "for posterity" on Github without incurring a $100/month bill, I simply create a master repo (say old-projects/) with all my unused repos in it.
On the other hand CodePlane seems to be a great solution for collaborative work on lots of private repos. This can save big bucks.
I love to see projects like this. I hope it gains some traction and forces Github to change their business model to a more manageable per-GB price.
The one-repo-for-old-projects solution works in some cases, but not really for mine. As a contract developer I often have projects that are under active development for a few months and then go into "maintenance mode". In this case I want separate repos for when maintenance needs to happen. Otherwise that one repo is a mess.
I believe this is the kind of problem that CodePlane solves. And I agree with you that its great to see projects like this present competition and make GitHub better in the long run.
It's a hack of course, but if the changes are really that occasional, the pain is negligible: all you need to do is to commit twice for every project change (once for a sub-directory containing the project repo, once for the root repo).
If a project becomes active again, simply take it out of the master repo and push it as a new repo.
It's really not that bad. But then again, things change if you have collaborators...
Can't you just use branches for this? Sugar code (git.sugarlabs.org) generally gets a new branch for each major release, which can be maintained separately from master.
I wanted to solve both problems. I have 40+ repos, but about 50% are archives only. So, with 2GB I can store them and I also work on my current projects.
I like this business model better. You pay for what you use, not how you use it. Its moving away from the Microsoft plan of "to use this for business you must pay me double".
Its like a ford salesman asking you about how you plan on using your ford focus, oh you will be driving to work? Highway driving costs you 50% extra. Sorry. You can take our back-alley car for cheap though.
as arturadib mentioned, you can make the "old-projects" repo. But that's just a hack/workaround for a wrong business model. Though I am sure this business model is much more profitable.
197 comments
[ 3.8 ms ] story [ 217 ms ] threadi just back up to multiple boxes, but i can understand why someone would want something centralized and specific.
I think the only thing i will miss from github, is the feature to view your code online.
Btw, I like both the idea and execution. Good luck... :)
> Please note: While we do not guarantee our free services, we do want to build a long-term relationship with you. So, even if you sign up today for a free plan, and we discontinue that plan, we provide service for at least a year after you sign up. We will add and remove our Free offers to meet customer demand. Enjoy what we have posted today, and check back regularly for additional offerings!
I couldn't find it for 5 minutes!
A similar thing happened to me a few weeks ago when I was looking for a way to add more repositories to a project. Luckily I got an answer quickly on their support forum (and yes, it was there).
So yes, the UI and information hierarchy is lacking, but ultimately it can do a lot of things.
(For future reference, you can change the settings under Stream - Email Notifications).
Admittedly some of their tools have small problems, but the team is responsive and improves it steadily.
I've used one of their paid programs for everything we do (must be about two years by now) and I would recommend it.
Assembla doesn't seem to have that social aspect like Github, but I find their combination of tickets, wiki, forum and repos more useful.
give me free accounts with a few MBs and you have yourself a user base.
github didnt get that size with 9/mo plans...
Makes sense?
Private code sharing. You have to install something like gitolite (see my other comment) to do private code sharing with git on a VPS, or you'd have to create a system-level user for every person you want to share code with.
It is one of their "one-click" installations and I have been pretty happy with it for my limited use.
Switching to Hg was a bit of work, but I've actually learned to like it more than Git. Really though, it's the same kind of thing and I just use both. So I ended up at bitbucket for the same reasons OP built a new site.
My way was quicker though.
I use bitbucket, too, because of the unlimited private repositories.
[1]: http://hg-git.github.com/ [2]: http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-...
I understand that bzr and hg are almost identical, command-wise, but hg is about as fast as git, is that correct? What my workflow consists of is diffs/statuses/commits/pushes/pulls in projects with working trees of a few MB at most.
Git is a great tool for what it was built for and the group of users it was intended for--that is, rapid, tons-of-merges-and-pulls development on a gigantic codebase, for users for whom it is acceptable for man pages to serve as reminders rather than instructions. However, I appreciate the additional attention paid to tooling and user-friendliness in Mercurial-land that make it more pleasant for me to use.
Hg is slower overall, but scales just as well as git. A huge repo will still be just slightly slower in hg than in git.
I was a paying GitHub customer until I decided that I spent too much money on online subscriptions. But when I'll pay for a Git hosting service again, I'm going back to GitHub, as I'm still a happy user of their free account. GitHub rocks.
Sure, competition is good, but I don't get what codeplane.com is offering, considering that configuring your own in-the-cloud repository is so easy on a VPS (that you're likely to have anyway and be left unused to its full potential otherwise).
Good job.
What about security? If i sign up, is my code safe if I want to keep a repo only for me?
I've done this for myself with a $48/year VPS from prgmr.com specifically because I needed more private repos than Github could offer (my setup instructions are here: https://gist.github.com/1035834).
Granted, if codeplane.com existed six months ago I probably wouldn't have bothered with gitolite. It appears they do nice things for you like backups.
Gitosis does not have as fine grained control as gitolite nor is it as well documented (config file errors are hard to debug), but it works well within its limitations. Both are now available as Debian/Ubuntu packages (gitolite was not when I started using gitosis). The other obvious difference is that gitolite is written in Perl and gitosis is written in Python. This should be a superficial difference, but sometimes the world isn't rational.
Gitolite on the otherhand is under active development, the documentation is great, and the author is generally available on the #git channel as are many other active users of the software.
http://www.exratione.com/2011/03/setting-up-an-access-contro...
Since I maintain my own sites anyway, keeping as many private repositories as I want is basically free once this is set up.
It's rather easy to set it up (as the comments here suggest), but seems like a lot of folks wouldn't want to go into trouble of learning about it and/or setting it all up properly, or don't have a server to put it on.
This is also a good opportunity to practice startup launching. Identify your target clients, where they are, what they are looking for, etc. Create a landing page with MVP offer description and subscription for availability notification. Check patio11's advices on optimizing the landing page. Then spread the word. The subscription feedback should give you a traction feedback. This should be enough to deduce the fee to reach break even as you launch. Assume only a percentage of subscribers will make the jump. If you can break even with only 10% subscribers adopting it, then things are sound.
I does look good from what info is available though.
Need redundancy because those fly-by-night VPS providers disappear? Fine, pick up another VPS from lowendbox.com and rsync your git home directory. Done and done.
On a side note, you could consider all your repos on your primary machine your "backup," as with a relatively static IP from a cable or DSL account you can push and pull to your hearts delight from your home box. Not great for collab, but sometimes I feel like the D in DVCS gets forgotten about.
Just wish Github would revise their pricing to support peeps like us, I hate to use different interfaces. May choose to just archive things to codeplane until then, keeping things we are actively developing on github.
To save my repos "for posterity" on Github without incurring a $100/month bill, I simply create a master repo (say old-projects/) with all my unused repos in it.
On the other hand CodePlane seems to be a great solution for collaborative work on lots of private repos. This can save big bucks.
I love to see projects like this. I hope it gains some traction and forces Github to change their business model to a more manageable per-GB price.
I believe this is the kind of problem that CodePlane solves. And I agree with you that its great to see projects like this present competition and make GitHub better in the long run.
If a project becomes active again, simply take it out of the master repo and push it as a new repo.
It's really not that bad. But then again, things change if you have collaborators...
Its like a ford salesman asking you about how you plan on using your ford focus, oh you will be driving to work? Highway driving costs you 50% extra. Sorry. You can take our back-alley car for cheap though.
as arturadib mentioned, you can make the "old-projects" repo. But that's just a hack/workaround for a wrong business model. Though I am sure this business model is much more profitable.