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

61–70 of 147 posts

Re: Fossil SCM

#61

Post by rkeene2 »

vkou wrote: post #57
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…

As a developer who hasn't learned git beyond the superficial, I second the notion that it is extremely esoteric.

Time to try Fossil :-)

Re: Fossil SCM

#62

Post by OJFord »

bananaoomarang wrote: post #51
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…

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)

No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.

Re: Fossil SCM

#64

Post by tacostakohashi »

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, and the Linux kernel was using BitKeeper... which no doubt encouraged a lot of the innovation in the open-source space.

Then, once Git was developed, got huge exposure and traction through the Kernel, and GitHub came onto the scene, it quickly became dominant - despite the alternatives, and despite the goofy interface.

Re: Fossil SCM

#65

Post by fundamental »

wirrbel wrote: post #8

Anyone using it for development? What is your experience?

I started to use it for one large project a few months back as I liked the idea of having an integrated issue tracker/docs/wiki/etc. In the end I wasn't a huge fan of fossil overall as its implementation felt clunky and I reverted back to git. I'd say most of it's problems can be attributed to a lack of polish due to the much smaller user base compared to other options like git.

Re: Fossil SCM

#66

Post by lvh »

OJFord wrote: post #62
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) No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.

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?

Re: Fossil SCM

#67

Post by reitanqild »

sevensor wrote: post #33
reitanqild wrote: post #25

Earlier quoted context omitted.

I tried to ask a couple of days ago if anybody has started using bitkeeper lately but either only one person saw it or only one other person found it interesting: https://news.ycombinator.com/item?id=13661662

I missed that, but I'm interested in the answer too. I believe the bitkeeper guy frequents this forum. Haven't tried it, myself.

Haven't tried it, myself.

Neither have I and I am a bit hesitant to throw all my tooling out of the window (ok, mostly hosted git + git extensions + builtin git + svn support in all my IDEs (Netbeans/VS/Rider).

Re: Fossil SCM

#68

Post by tacostakohashi »

hubert123 wrote: post #9

I dont see the point of Fossil, I looked into it. The commands arent that much easier to understand. If I'm using an SCM anyway and I still need to use a cmd line and I still need to memorize commands then I might just as well use git. And Git has Guis now.

Without having looked into the details... I do rather like the idea of an SCM with a built-in ticketing / documentation (wiki / markdown rendering system).

These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks.

It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.

Re: Fossil SCM

#69

Post by lvh »

wirrbel wrote: post #8

Anyone using it for development? What is your experience?

I've used it quite a bit, and I'm happy with it. My main gripe (and it's not much of a gripe): editor integration. There's vc-fossil, but vc incompatibly changed its API between Emacs24 and Emacs25. While I generally don't like git very much, magit is amazing (and, honestly, the only reason I can put up with git).

Re: Fossil SCM

#70

Post by rbehrends »

iso-8859-1 wrote: post #22
BeetleB wrote: post #11

Earlier quoted context omitted.

Genuinely curious: Why do you need rebasing? I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?

If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits. Some repositories, like Rails have a lot of merge commits. Why should I have to read through them? Also, all kinds of failed tests may have been developed in a feature-branch during month-long development. Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underl…

> If you like a readable commit history, rebase is useful to reorder and squash unnecessary commits.

This is an artifact of Git. There are two principal solutions that do not require rebase.

1. Use Bzr-style hierarchical logs. This could in principle be used as a UI on top of Git. Here, merging rather than rebasing actually improves the readability of history.

2. Have fully labeled branches. This allows you to filter and visualize commit history based on branch membership. This is the approach traditionally used by most non-Git version control systems, but is not really viable in Git, because Git lacks the necessary meta information.

Post reply on HN