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

Fossil SCM

fossil-scm.org

Post reply on HN
Print view View original

111–120 of 147 posts

Re: Fossil SCM

#111

Post by david-given »

maxpert wrote: post #10
cmrx64 wrote: post #5

Fossil is the SCM I always wish I were using, but for the benefit of external collaborators, I stick with Git and GitLab (previously, GitHub). Fossil is a lovely, small piece of software that does exactly what I want in a nice and simple way. It's fast and uses SQLite for everything, making it easy to programmatically extend it and munge its internal data.

SQLite usage makes me wonder how will it behave over time with millions of commits. Also makes me wonder how will it handle distribution.

There's a writeup here about scaling issues in moving NetBSD pkgsrc to Fossil:

http://fossil-scm.org/index.html/event?name=be8f2f3447ef2ea3...

But that was, like, 2011, so I have no idea if it's still valid or not.

Re: Fossil SCM

#112

Post by petre »

bachmeier wrote: post #40

Here's my story. I wanted to use version control on my research projects, but asking my collaborators to use Git was too much. They were supposed to figure out a staging area and pushing and pulling and then they'd get a bizarre error about a merge conflict. They'd do a search and Stack Overflow told them to type in an incantation. The repo is messed up, the collaborator goes back to email, and I'm left sorting throu…

We've been using it as well for at least three years. I can get stuff done with fossil without having to read man pages and search for examples every time I'm doing something different. It's also suitable for teams that require a central repo as everything could be kept in sync with upstream with the added ability of hassle free branching and merging (svn I am looking at you), stashes and other git-like goodies.

The only problem is that once the history gets big enough, fossil gets slow. Everything is replicated everywhere which is an advantage (backups everywhere) but also a drawback (slow). I once tried to convert the FreeBSD ports tree to fossil and gave up after some hours and gigs of data.

Mercurial was interesting and user friendly as well, but it requires python. Fossil is a single self contained binary with everything in it. And so is the repo - a single SQLite database. No .svn dirs scattered all over the place.

Re: Fossil SCM

#113

Post by oblio »

gkya wrote: post #72
bananaoomarang wrote: post #51

Earlier quoted context omitted.

This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is. I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c. Maybe this is to do with our desire for everything to be…

> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c. While I agree that there are those who take pride in how spartan tools they use, it's not correct to make blanket judgements about the whole suite of hackerware . Emacs, for instance, is not diff…

Emacs is not difficult to use?

In order to get it to do half of what Notepad++ or Sublime or Kate do, you have to spend hours and hours to learn it and configure it in the hope that the investment will pay off and that the productivity gain will make up for it. And despite what you might say there's no data you can point me to that actually proves those increased productivity claims.

Re: Fossil SCM

#114

Post by oblio »

tacostakohashi wrote: post #64
maxpert wrote: post #6

It's good to see so many SCM systems showing up. But it makes me wonder how many of them can actually work on GBs of codebase with over 1000 of programmers checking in on daily basis. I my experience most of SCMs are fine for small to medium projects, but they go down with crawling speeds and sometimes even not working at all when it goes large scale.

Hmm, really? It's hard to measure objectively... but my perception was always that there was an explosion of SCMs around the early-mid 2000s, after everybody got sick of CVS, but eventually Git won out and a lot of the alternatives / diversity in the space went away. Within short succession, there was Subversion, Arch, Darcs, Quilt, Bazaar, Mercurial. On the commercial side, perforce had a certain amount of traction,…

SVN is still quite popular. I'd definitely not bundle it with Arch, Darcs, Quilt or Bazaar, in that regard ;)

Re: Fossil SCM

#115

Post by sytse »

pythonaut_16 wrote: post #109
sytse wrote: post #93

Earlier quoted context omitted.

Glad to hear you're considering using GitLab. We have an importer for Gitea but not for Gogs https://docs.gitlab.com/ee/workflow/importing/README.html so I think you might consider a batch import https://docs.gitlab.com/ce/raketasks/import.html

I just started using this yesterday! I setup a personal Gitea instance on Linode, but wanted to make sure I could easily back up my repos in case I ever lose access or stop maintaining my personal Linode server. Gitlab made it easy to setup all of my repos to mirror and automatically update from my Gitea daily. (One slight bug, Gitlab does seem to always say the repos failed to import, even when they're successful) T…

Great to hear you're using GitLab already. Please consider creating an issue for the 'repos failed to import, even when they're successful' that allows us to reproduce it.

Re: Fossil SCM

#116

Post by cuspycode »

For me, the ease of self-hosting my own source-code hub tipped the balance in favor of Fossil SCM, after I abandoned Subversion. Ironically, the difficulty of self-hosting Git was the raison d'être for why inherently centralized services such as Github/Gitlab/etc were created in the first place, despite all the nice talk about distributed systems. There is no a priori reason why hosting a source code repo should be any different from hosting any random blog page. And Fossil is the proof that it can work.

Re: Fossil SCM

#117

Post by david-given »

lvh wrote: post #52
pebblexe wrote: post #45

I wish it supported AJAX and the client UI was decoupled from the repository.

I'm not sure I understand what you mean with "client UI being decoupled from the repository". Wouldn't everything you do in an SCM necessarily be coupled to a repository?

If you have multiple repositories, you have to set up the UI and ticketing setup in each one individually. (Although you can share a login database.)

I don't know if it's been fixed by now, but back when I was using Fossil regularly there were long-standing bugs where pushing the UI and ticket configuration from one repo to another didn't work properly, so synchronising look and feel across multiple repositories was hard.

Re: Fossil SCM

#118

Post by lvh »

OJFord wrote: post #97
lvh wrote: post #66

Earlier quoted context omitted.

Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes) mean that git gets useful new features?

> Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes) Branch management: # creation git branch foobar # listing git branch # renaming git branch -m barfoo # relocation git branch -f barfoo # deletion git branch -d barfoo Working directory management:…

I think we're mostly in violent agreement that there's a pretty steep learning curve. That is also true for some other tools. I'm questioning the link between steep curve and powerful; it is true that many powerful tools have steep learning curves; but one can easily think of tools that have steep learning curves but are not powerful. So, the question is: is git's CLI just weird, or does it need to be weird in order to be successful as an SCM? (I think it's the former.)

Re: Fossil SCM

#119

Post by pestaa »

sytse wrote: post #91
eslaught wrote: post #87

Earlier quoted context omitted.

The issue is not that Gitlab is missing any of the pieces. The issue, I believe, is the organization of such pieces so that you can find them intuitively. This is admittedly a lot better in Gitlab today that it used to be. When I started, I literally could not figure out basic things like how to get to a specific repository inside of an organization. It also doesn't help that Gitlab has chosen to use its own jargon f…

Thanks for the response, and I'm glad that it is better than it used to be. In GitLab people can have a project without a repository, for example with just a wiki or an issue tracker. For that reason we use different words for it. Single people also use GitLab as a single tenant we prefer to use the word group over organization. That will also fit better when we introduce nested groups in GitLab 9.0 https://gitlab.co…

Thanks for the open discussion!

As eslaught pointed out, it's not about the obvious mistakes.

Unfortunately, the navigation is very fragmented. There's a left menu, which should be the primary one, but it changes all the time depending on the context.

The top menu is very inconsistent, presented in multiple layers, with different styles for each level, using very low contrast text with no other visual aid. There are no dropdowns or other ways to get to frequented pages faster. Being aligned to center also prevents me from memorizing the UI spatially (YMMV).

And there's also the issue with minimalistic buttons acting like links.

It is my humble opinion that rewriting the frontend in Vue will not, by itself, alleviate the matter; however, fixing this part of the UX will make GitHub and Atlassian really run for their money.

Re: Fossil SCM

#120

Post by gcb0 »

bachmeier wrote: post #40

Here's my story. I wanted to use version control on my research projects, but asking my collaborators to use Git was too much. They were supposed to figure out a staging area and pushing and pulling and then they'd get a bizarre error about a merge conflict. They'd do a search and Stack Overflow told them to type in an incantation. The repo is messed up, the collaborator goes back to email, and I'm left sorting throu…

if the workflow magically avoids conflicts, why not give them 2 commands to update/commit&push and keep all the power of git to who need it?

also, you do know that conflicts are going to show up eventually right?

Post reply on HN