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

131–140 of 147 posts

Re: Fossil SCM

#131

Post by lvh »

__david__ wrote: post #94
tacostakohashi wrote: post #82

Earlier quoted context omitted.

I disagree completely - I think these things have the same properties as source code. Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.

You might like https://github.com/brandonson/evict . I used to use `ditz` but it was abandoned years ago and was tied to Ruby 1.8 in a bad way. I've been meaning to switch to evict but haven't ever been able to get it to compile :-).

IIRC, ditz and evict and b-e and ticgit and... all don't solve a problem for public projects which fossil does: random people on the Internet need to be able to submit bug reports.

Re: Fossil SCM

#132

Post by lvh »

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…

That's true, but also means that there's a fake intermediate stage that never actually existed in the WT, and hence definitionally was never linted or tested.

Re: Fossil SCM

#134

Post by jccooper »

rkeene2 wrote: post #90

I would also like to mention ChiselApp ( http://ChiselApp.com/ ) offers free Fossil hosting. I run this service, originally run and created by James Turner.

Thank you super much!

Re: Fossil SCM

#135

Post by gglitch »

ubercore wrote: post #20
spraak wrote: post #12

Earlier quoted context omitted.

I couldn't find any screenshots on the site, can you share any?

I believe the site itself is running an instance of Fossil?

Yep. Cloning it is also a great way to poke around and get a better sense of its functionality.

Re: Fossil SCM

#136

Post by kaushalmodi »

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.

You are comparing Emacs with Notepad++. You are then not using Emacs as it's supposed to be.

The actual power of Emacs is realized once you learn elisp. Coding, documenting, commiting, blogging, browsing, file/dir manipulation, etc. all can be done efficiently using the same familiar buffer editing philosophy within Emacs.

Re: Fossil SCM

#137

Post by planteen »

BeetleB wrote: post #38
maxpert wrote: post #10

Earlier quoted context omitted.

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

To be honest, I'm very wary of using SQLite for storage for anything long term. Over the years I've had a few SQLite databases become corrupt in various software I use. Always a headache.

Just curious, were you running with ECC RAM on the box?

Re: Fossil SCM

#138

Post by jjirsa »

BeetleB wrote: post #11
jjirsa wrote: post #3

No/manual rebase sounds awful

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?

I regularly need to apply patches written months/years ago to a branch that's changed many many times (maybe a thousand) - for example, patch written at a specific point in time spends 2 months being reviewed, and by that time it no longer cleanly applies to trunk.

Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk

Re: Fossil SCM

#139

Post by e12e »

sytse wrote: post #93
e12e wrote: post #80

I tried using Fossil as a DVCS/Project management tool for a class I'm currently teaching - but in the end I couldn't quite figure out self-registration combined with allowing authenticated push in a way that worked for ~25 students without needing much instruction/hand-holding. If I'd had some form of user-database already, I could probably have gotten it to work with a proxy in front - but for now I've ended up usi…

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

Thank you for the tip about gitea, which appears to be a fork of gogs:

https://blog.gitea.io/2016/12/welcome-to-gitea/

I'll check that out first I think - I really like the ease of deployment with gogs, so if the project have some features a little more ironed out - it might be just what I need.

Re: Fossil SCM

#140

Post by zzalpha »

throwawayish wrote: post #103
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…

> 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. This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and…

I think that's a bit unfair. It presumes git is trying to abstract it's internals in the first place.

It's not.

Git is unapologetically a tool for manipulating a DAG, and puts that right in your face.

This has pros and cons. The obvious con is that it has an immensely steep learning curve and, for users who cannot develop a mental model for how it works, forces people to rely on cargo culting.

The flipside is that it's more powerful than any SCM I've worked with, as the lack of any abstraction means you can do nearly anything you like to that DAG.

Heck, let's take this example originally posted. The remote repo has changed. Okay, well, the common case is probably to pull and... wait, merge or rebase local changes? Git gives you the choice. Other tools might not.

All that said, git could certainly be made a lot less esoteric. The command set is inconsistent and poorly named (I'm looking at you 'git reset'). And the error messages leave a lot to be desired.

As for doc, I completely disagree. I've built git training modules and my primary sources are the git docs. They're quite thorough (though they have the fault of being heavily steeped in git jargon).

Post reply on HN