Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Use Fossil

sheddingbikes.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Why I Use Fossil

#41

Post by zedshaw »

gecko wrote: post #24

While I love the idea of Fossil, I think Zed downplays a lot of the problems that it has in reality. There's no real way to throw out branches easily, nor is there any rebasing. Fossil doesn't track renames, so if you rename files in a branch, you'll need to rename them again on mainline before the merge. Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm i…

This is load of FUD and you know it. First, your claims are completely from your experience, like email patch management. Only a few projects use that, and most just tell you to put it in a Trac or similar.

Second, all the things about "not being to see X" are configurable. But, then again I can't expect you to actually research a system before you go talking about it, 'cause that'd interfere with your FUD.

Third, rebasing is both a load of crap, and also not as necessary in fossil by design. It has a much more strick auto-commit mode that gets rid of plenty of problems with needing to rebase. In fact, I wish all the SCMs did this optionally.

Finally, it has a bug tracker. Come talk to me when Trac is DAG based.

So, you've demonstrated you know jack squat about fossil, then you come on here and talk like you are some authority on it and "other projects", then say "I would strongly encourage caution." like the world will end.

My only question is: How long did you work at microsoft? :-)

Re: Why I Use Fossil

#42

Post by zedshaw »

Goosey wrote: post #26
gecko wrote: post #24

While I love the idea of Fossil, I think Zed downplays a lot of the problems that it has in reality. There's no real way to throw out branches easily, nor is there any rebasing. Fossil doesn't track renames, so if you rename files in a branch, you'll need to rename them again on mainline before the merge. Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm i…

"You can create branches by doing multiple commits off of the same base version." It doesn't sound hard, but perhaps I am missing something?

No he's full of it. Branches are just tags on leaves. In fact, you can read about it on the website, but of course that'd involve actually trying to understand something first before talking about it.

Re: Why I Use Fossil

#43

Post by zedshaw »

pjhyett wrote: post #31
masklinn wrote: post #19

Earlier quoted context omitted.

Exportable is not the same thing as naturally distributed though. And git-backed is nice, but with fossil it's fossil-baked as everything is tucked into the exact same repository. > Wikis are first up and we're very close. Well yeah but as far as I understand, with Fossil it's done already, not just close (and I'd say distributed bug trackers are closer than wikis if not done already)

Integrating those systems directly into Fossil seems like a poor design decision. Everyone has different requirements and it directs focus away from the core responsibility of a VCS. Do one thing well and all that good stuff.

Yes, if you narrowly define VCS as "shoves code around". If you define it as "versioning the code and related project material" then it's exactly what should be in the tool. In fact, I predict this will be the next iteration of project management tools, where everything is stored and managed in git/hg/mercurial, so the next logical step is what fossil does.

Re: Why I Use Fossil

#44

Post by zedshaw »

gecko wrote: post #23
gcv wrote: post #7

I looked at Fossil a few months ago. I basically liked it, but Fossil (1) didn't do Git-style file rename detection, and (2) didn't have "git add --patch" functionality. Has this changed? I can't really use an SCM without those features anymore.

Forget rename detection ; it doesn't do renames period . So if you rename a file in one branch, you need to rename the file in the other branch BEFORE the merge, or you'll simply end up with two different files with different names.

Sigh, bullshit. I do this every day and it's just fine. You must be referring to some other concept of rename in some bizarrely complicated configuration you've worked yourself into.

Re: Why I Use Fossil

#45

Post by zedshaw »

stonemetal wrote: post #15
mkramlich wrote: post #3

he gave reasonable arguments, assuming one does always want all of those extra features beyond VCS for each new project. for me, most of the projects i start never need to go public, and of those that do, most don't need a full-blown wiki or issue tracking system. README and TODO file are sufficient 99% of the time, esp with no public collabs. so git and github still hit the sweetspot for me in the default case.

I didn't find his arguments that compelling. User management is something you are going to have to do no matter what VCS you are using Fossil doesn't remove that requirement. Last I checked Fossil didn't magically generate custom CSS and project logos so I am still going to have to do all that stuff with fossil. Pretty much every thing on the if I don't use fossil I will have to do this extra stuff is stuff you have…

"User management" in other systems involves either copying ssh keys or using a service like github. If it's Trac you're talking about then depending on the version either you're doing command line operations that make no sense, or maybe you got one of those fancy web admins.

The point was, fossil has a nice flexibly but easy to use integrated user management. I can go in and say that anonymous users can post tickets or not, commit or not, clone or not, all fine grain. I haven't ran into a single system that does this nor does it this easily.

Re: Why I Use Fossil

#46

Post by nex3 »

bruceboughton wrote: post #39
nex3 wrote: post #37

Earlier quoted context omitted.

I can see arguments both ways. Having the wiki separate means that the repo doesn't get polluted with unrelated commits (especially important for SVN which doesn't have branches), and it makes setup at least somewhat easier, since an extra push-capable user doesn't need to be added.

>> (especially important for SVN which doesn't have branches) explain.

Subversion doesn't have a built-in notion of branches in the same way that distributed systems do. Instead of being names for nodes in the DAG of commits, branches in Subversion are usually handled by manually maintaining separate versions of the same code in a branches/ subdirectory. In a distributed system, you could keep a wiki or bug database on its own branch, and commits to that branch wouldn't be visible if you only cared about the main branch. In Subversion, those commits would be visible, because it's all part of the same tree.

One caveat: Subversion's branch management may have changed since I last looked (version 1.5 or so). However, systems like Trac and RedMine were designed when branches worked as I described above, so it still serves to explain their rejection of SCM-backed storage.

Re: Why I Use Fossil

#47

Post by raggi »

gecko wrote: post #24

While I love the idea of Fossil, I think Zed downplays a lot of the problems that it has in reality. There's no real way to throw out branches easily, nor is there any rebasing. Fossil doesn't track renames, so if you rename files in a branch, you'll need to rename them again on mainline before the merge. Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm i…

"Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm involved with."

Don't you use 3 sites, one you write that try to optimise away from this ghetto process?

I had a look at your accounts, some of your projects have 0 followers, and your average follower count is around 0.9. You can calculate your average commit and contributor volume on your own, or maybe write that into Kiln.

If your download count just increased to 1, that's because I accidentally clicked between the headings and got a .gz file with an attachment header from the server (wtf?).

I think the most important thing in the original article is the serious point that there are plenty of us out there who have to know and use all of the SCMs and tbh, they aren't really that different. All the ones I use in OSS do one major job: SCM. Even as you put it on your blog "the enemy of git and mercurial" (wtf?) subversion actually does a good job at this. For a long time it was king, too. In fact, I still miss the svn/trac combo, but Zeds point about this being a shit to setup and consuming way too much by way of server and admin resources is spot on the money. Not wanting some commercial venture to host it for you / or not liking their specific feature set is taste, but it won't stop anyone that matters from using your code, or submitting patches.

Man I should never come to HN, clearly.

Re: Why I Use Fossil

#48

Post by fffffffffffffg »

gecko wrote: post #24

While I love the idea of Fossil, I think Zed downplays a lot of the problems that it has in reality. There's no real way to throw out branches easily, nor is there any rebasing. Fossil doesn't track renames, so if you rename files in a branch, you'll need to rename them again on mainline before the merge. Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm i…

If you actually cared about being responsible for your own data you'd see that Github is a not a competitor with Fossil in anyway. It doesn't offer the feature of you being responsible for your own data, it doesn't allow you host your wiki, bugtracker offsite in a DAG like you ask.

It doesn't allow you to be responsible for your data. This is why github and fossil are worlds apart.

Fossil is a product. Github is a service.

Here are more distributed issue trackers and these are PRODUCTS not SERVICES: http://lwn.net/Articles/281849/

http://www.ditrack.org/ Subversion based multi headed issue tracker

http://www.distract.wellquite.org/ - A web browser based interface one

http://ditz.rubyforge.org/ Distributed issue tracker

Something comparable with Github would be gitorious.

http://www.gitorious.com/

Re: Why I Use Fossil

#49

Post by mml »

trainwreckin wrote: post #13

Ugh. Zed, like drh miss the point yet again because they are closed minded programmers and keep on forgetting that people who are not programmers may end up using fossil as they wish to contribute a ticket or documentation to a project running on fossil, but get reluctant dealing with the crappy UI or the fact that they have to learn to do markup. It's also clear that drh really isn't interested in anybody else but h…

Just because lots of your buddies use it, doesn't make it useable. Git approaches the useability of iptables, which is to say, utterly unusable unless you have the manpage tattooed on you arm.

Re: Why I Use Fossil

#50

Post by Tichy »

pjhyett wrote: post #6

If I may quickly address Zed's concerns about putting his code on GitHub: 1. GitHub is a node on a distributed graph, you're still in full control of your source and its history thanks to Git. Push your code to a dozen different places, Git doesn't care and neither do we. 2. We have soft disk space limits. If your OS project is massive, we're not going to suddenly start charging you if you exceed that space. We want…

I think that the concern with #1 was not having one's stuff one somebody else's server. It is that if said server becomes unavailable, there is no alternative left. So if you bet on git, how do you get your nice wikis, bug trackers, HTTP access and whatnot without GitHub?
Post reply on HN