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

121–130 of 147 posts

Re: Fossil SCM

#121

Post by Lxr »

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…

Would you mind sharing what some of these little programs do?

Re: Fossil SCM

#122

Post by jazoom »

sytse wrote: post #83
pestaa wrote: post #2

GitLab contributors, please take note. Fossil's UI is very fast and the navigation is intuitive and discoverable. I know it's on the roadmap, but it is so often an afterthought.

Thanks, we're indeed working on making the UI faster in https://about.gitlab.com/2017/02/06/vue-big-plan/ I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation: 1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something. 2. Fossil timeline seems similar to GitLab Activity http…

I've been using GitLab for a couple of years now and it's true that finding stuff is not very intuitive. Even now I still have trouble finding things. Maybe you should watch many new people using it to see where they get stuck.

Re: Fossil SCM

#123

Post by bachmeier »

gcb0 wrote: post #120
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?

> if the workflow magically avoids conflicts, why not give them 2 commands to update/commit&push

The workflow doesn't avoid conflicts.

> keep all the power of git to who need it

Git provides no useful features over Fossil for what we're doing.

> you do know that conflicts are going to show up eventually right

And when they show up with Git, boy do they show up.

Re: Fossil SCM

#124

Post by fundamental »

rkeene2 wrote: post #110
fundamental wrote: post #65

Earlier quoted context omitted.

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.

What issues did you have ? Fossil is usually pretty easy to cleanup any dangling wires, if they can be coherently identified to people who may not see them in the same way as you.

It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (for tickets I ended up building a TUI as a workaround https://github.com/fundamental/fs-tickets (the original fossil repo is sitting around somewhere)); there was no 'fossil grep'; the lack of a staging area was annoying when sorting through exploratory changes (git add -p and vim's git-fugitive options make the staging area hugely useful); attaching files to issues/wiki/etc was difficult; setting up a remote which could be pushed/pulled from (with multiple machines) was difficult; and I recall the username + password combo failing in a way that I never diagnosed.

Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.

Re: Fossil SCM

#125

Post by rkeene2 »

fundamental wrote: post #124
rkeene2 wrote: post #110

Earlier quoted context omitted.

What issues did you have ? Fossil is usually pretty easy to cleanup any dangling wires, if they can be coherently identified to people who may not see them in the same way as you.

It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (for tickets I ended up building a TUI as a workaround https://github.com/fundamental/fs-tickets (the original fossil repo is sitting around somewhere)); there was no 'fossil grep'; the lack of a staging area was annoying when sorting through exploratory changes…

Many of these issues have likely been resolved.

Wiki supports the wiki format, markdown, and HTML now.

There is now a "fossil search" command for full-text search (including artifacts, if enabled).

I've never had a username/password failure so no idea what that could be.

For tickets, icomment is probably the solution you want but it's not very intuitive.

git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.

Re: Fossil SCM

#126

Post by rkeene2 »

vonuebelgarten wrote: post #102
rkeene2 wrote: post #50

Earlier quoted context omitted.

Fossil's emphasis on recording history is very helpful. Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful. Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository. No multi-stage commit pipeline is much easier conceptually -- mostly…

>No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream. But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be…

Fossil's default mode, autosync, is more closely modeled by: git pull && if stillCommitingToBranchTip; then git commit -a; else echo "Not committing to the tip of the current branch" >&2; false; fi && git push

You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area.

This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.

Re: Fossil SCM

#127

Post by gglitch »

I use Fossil for all my personal projects, and I use its wiki, technotes, and tickets for almost all of my knowledge and task management. It has become the centerpiece of my workflow. Where else have I seen as great a combination of reliability, simplicity, and flexibility? Oh yeah, SQLite. Thanks drh.

Re: Fossil SCM

#128

Post by gkya »

Lxr wrote: post #121
gkya wrote: post #72

Earlier quoted context omitted.

> 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…

Would you mind sharing what some of these little programs do?

A little thing to show a compact weather forecast [1], a basic fronted to FreeBSD pkgng, a frontend to zx2c4's pass, some other utilites.

[1] http://www.gkayaalp.com/emacs.html#forecast.el

Re: Fossil SCM

#129

Post by gkya »

oblio wrote: post #113
gkya wrote: post #72

Earlier quoted context omitted.

> 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.

> In order to get it to do half of what Notepad++ or Sublime or Kate do

Do they have anything remotely like Gnus or Org-mode? Tramp? Magit? VC mode? SLIME? EMACS IS NOT A TEXT EDITOR. It is a Lisp interpreter with many applications written in it which happens to have a text UI and a text editor in its standard distribution.

Re: Fossil SCM

#130

Post by lvh »

qznc wrote: post #79
tacostakohashi wrote: post #68

Earlier quoted context omitted.

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 -…

On the other hand, it does not make much sense for ticketing and documentation to be distributed. They inherently must be centralized for a project.

Because fossil comes with a web server and a wiki, there typically is one blessed instance for any project. That's not too weird; after all, that's basically true fro pretty much everything maintained on GitHub too -- the only difference is you get the issue tracker and wiki in the repo.
Post reply on HN