1 year ago: https://news.ycombinator.com/item?id=9330482
What changed? Is BitKeeper still an ongoing business with some other model, or is that, as they say... it? I hope not.
What changed? Is BitKeeper still an ongoing business with some other model, or is that, as they say... it? I hope not.
Too late? Maybe. But we had a viable business that was pulling in millions/year. The path to giving away our stuff seemed like:
step 1: give it away
step 2: ???
step 3: profit!
Will it work? No idea. We have a couple of years to find out. If nothing pans out, open sourcing it seemed like a better answer than selling it off.
I'm also interested how open-sourcing BK will improve the other systems, too.
#mercurial in Freenode right now is monitoring this thread, very relevant to our interests.
Someone at Facebook in #mercurial right now is trying it on some Facebook repo, to compare performance.
How / why did you decide to use the Apache license rather than the GPL?
(It seems like a viral license might protect you a little bit, if you want to prevent your competitors from forking and improving your code base and then using it to compete against you.)
As to why that license, I think it was because LLVM or clang or both had recently picked that and all the lawyers at all the big companies liked that one. We don't particularly care, if everyone yells that it should have been GPL we'll fork it and relicense it under the GPL. Our thought was that Apache is well respect and even more liberal than the GPL but we can be convinced otherwise.
Also, replying to something a little higher in this thread, I wouldn't say that Apache 2 defines all contributions as Apache 2. That section of the license starts with the words "5. Submission of Contributions. Unless You explicitly state otherwise, ..."
And so Apache 2 just becomes the assumed default license on contributions, but it's not at all forced or required that contributions come in under Apache 2.
Well clearly in retrospect, step two should have been renaming it "Dawson's Creek Trapper Keeper Ultra Keeper Futura S 2000" [1], adding incredibly advanced computerized features including a television, a music player with voice recognition, OnStar and the ability to automatically hybrid itself to any electronic peripheral device, absorbing the secret military computer at Cheyenne Mountain, and taking over the world.
[1] https://en.wikipedia.org/wiki/Trapper_Keeper_(South_Park)
Looking forward to some hopefully differentiated features.
Bitbucket has been rotting since Atlassian bought them, and now there's really no "killer app" for Mercurial hosting. There are Mercurial hosting services out there, but nothing anywhere close to Github/Gitlab.
Actually since BK is now opensource we might think of adding a BK backend to RhodeCode and our VCS abstraction layer that already supports GIT, Mercurial and Subversion
I haven't checked out Bitbucket because last time I evaluated (2+ years ago) they didn't have good on-prem options.
I'm just not super-fond of relying on Bitbucket, reliable though they've been, for hosting my stuff.
But a package I could toss on my own VPS? I'd toss some money at that. Wouldn't even need it to be open-source, but I'm no zealot.
Care to be more specific?
I'll grant that Fossil's wiki is not a competitor to MediaWiki, but that doesn't make it "awful." It just makes it less featureful. So, what feature do you need in a wiki that Fossil's wiki does not provide?
As for the ticketing system, again, it isn't going to replace the big boys out of the box, but it also doesn't have to match them feature-for-feature to be useful. Also, the Fossil ticketing system's behavior is not fixed: it can be modified to some extent to behave more like you need. Did you even try modifying its behavior, or are you just complaining about its out-of-the-box defaults? Be specific!
> unexpected behavior for basic commands like "fossil rm".
If you mean that you want fossil rm to also delete the checkout copy of the file in addition to removing it from the tip of the current branch, and you want fossil mv to rename the checkout copy in addition to renaming it in the repository, then you can get that by building Fossil with the --with-legacy-mv-rm flag, then setting the mv-rm-files repository option. You can enable it for all local Fossil repositories with "fossil set mv-rm-files 1".
Alternately, you can give the --hard flag to fossil mv and fossil rm. That works even with a stock binary build of Fossil.
> I'm just not super-fond of relying on Bitbucket
For some of us, relying on a cloud service just isn't an option. We're willing to give up many features in order to keep control of our private repositories.
> a package I could toss on my own VPS? I'd toss some money at that.
Fossil runs great on a VPS, even a very small one, due to its small footprint. I wrote a HOWTO for setting it up behind an nginx TLS proxy using Let's Encrypt here:
https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
I also ditched it all 3 or 4 years ago, so my memory's not great, but what got me about the ticketing was that, for whatever reason, I could not sit any non-technical user in front of it and have it make sense to them. No amount of tweaking ever made it make sense for anyone but the devs. I know that's not specific, but this is all in the pretty distant past for me, and that's the takeaway I had from it.
Fossil's lack of any built-in emailing was also lousy. I'm aware that some people rig up some hokey RSS-to-email system to accommodate that, but really, come on, that's awful!
Hey, if fossil actually serves your needs, that's great. I like the value proposition--one file is your repo, wiki, tickets, the whole ball of wax, it's cross-platform, it's just that the execution of the idea didn't work for me.
(As an aside, another thing I didn't like about fossil was its community--tending toward defensiveness and "it's supposed to work that way" instead of "hey, maybe you, the user, are onto something".)
So name a bug tracker with equivalent or greater flexibility to Fossil's that non-technical users do understand.
I've only used one bug tracker that's simpler than Fossil's, and that's because it had far fewer user-facing features.
Every other bug tracker I've had to use requires some training once you get past the "submit ticket" form. And a few required training even to successfully fill that out!
> Fossil's lack of any built-in emailing was also lousy.
Email is hard. Seriously hard. RFCs 821 and 822 are only the tip of an enormous iceberg. If Fossil only did the basics, it would fail for a whole lot of real-world use-cases, and it'll only get worse as email servers get tightened down more and more, to combat spam, email fraud, domain hijacking, etc.
I, too, would like Fossil to mail out commit tickets and such, but I'm not sure I want the build time for the binary and the binary size to double just because of all the protocol handlers it would need to do this properly. Keep in mind also that Fossil generally doesn't link out to third-party libraries. There are exceptions, but then, I'm not aware of a widely-available[1] full-stack SMTP library, so it would probably have to reimplement all of it internally.
Now, if you want to talk about adding a simple gateway that would allow it to interface with an external MTA, that would be different. I suspect the only thing wanting there is for someone to get around to writing the code. I don't want it bad enough to do it myself.
> "it's supposed to work that way" instead of "hey, maybe you, the user, are onto something".)
If you propose something that goes against the philosophy of Fossil, then of course the idea will be rejected. We keep seeing git users ask about various sorts of history rewriting features for example. Not gonna happen. No sense having a philosophy if a user request can change it.
If you're talking about a Fossil behavior that isn't tied to its philosophy, but it just works the way it does for some reason, logic and persuasion are a lot less effective than working code. The Fossil core developers accept patches.
----------
[1] I mean something you can expect to be in all the major package repositories, and in binary form for Windows.
I still think the Fossil value proposition--one file with all your project ephemera--is a good one. It'd be neat if BitMover produce something similar, e.g. maybe not a file, maybe a directory, but same idea, etc.
It's a good excuse to blame that opensource broke your business, and that opensource could not save you from dying...