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

Fossil Chat

fossil-scm.org

Post reply on HN
Print view View original

131–140 of 172 posts

Re: Fossil Chat

#131

Post by sgbeal »

gglitch wrote: post #108
sgbeal wrote: post #85

Earlier quoted context omitted.

> If I could be so unproductive... It goes much further than that... When one views a fossil-hosted forum post from the main fossil site or sqlite's site, they are looking at... - A forum post rendered by software Richard wrote. - Piped out to you via an HTTP server he wrote. - Served from an SCM he wrote. - Stored on a database package he wrote. - All coded in a text editor he wrote. Complete vertical integration. H…

What's the text editor? If anything could get me off Emacs, it'd come from the Hippoverse.

> What's the text editor? If anything could get me off Emacs, it'd come from the Hippoverse.

It's a basic tk-based app, IIRC. i peaked at it once when he posted a link to it, but that was 7+ years ago and i don't recall where it lives. No syntax highlighting, no configurable options (beyond editing the source code), very much built for his personal coding style.

You don't want to leave emacs. Emacs loves you. Trust emacs.

Re: Fossil Chat

#132

Post by sgbeal »

zzo38computer wrote: post #109
HeckFeck wrote: post #2

Does anyone use Fossil? I'm considering it for my personal projects. I like all it offers for the relatively low resource usage. The only use of it I've seen in the wild is Ripcord ( https://dev.cancel.fm/issues ), which is interestingly also relatively low resource usage compared to its competitor.

I use Fossil for my own projects. However, I do not use the forum feature, chat feature, etc. They don't belong there in my opinion, nor do I like the implementation much; I use external software. There are a few other things I dislike about the design of Fossil; it doesn't have very good low level access, for one thing (there are other concerns too, although rebase isn't one of them). I have started to make my own i…

> Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority,

That's me (https://fossil.wanderinghorse.net/r/libfossil). The protocol is irrelevant to the implementation of the underlying core algorithms and data format. The sync protocol is a completely separate layer which can be reimplemented any number of ways without affecting the underlying data model. Without the core data model and algos implemented, the sync protocol is useless because it has nothing to sync.

Ergo: first implement the data model, then the sync.

> (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it)

That's a really interesting topic, actually. The core data model is 100% independent of any given schema (or storage model, for that matter), so anyone implementing a compatible (at the data model level) tool is free to use whatever storage or schema they want. The fact is, though, that libfossil could never have gotten as far as it has without re-using much of what Richard has already designed, and that includes the schema and core SCM-relevant algorithms. As a long-time fossil contributor, it's important to me that the libfossil tools be as compatible as feasible with fossil, and that means using the same schema (for better or worse).

That said: i would very much like to see the core data model implemented on top of another schema, just to see it done. Alas, i don't have the energy to create, from scratch, such a beast, nor to maintain it, so my path is one of lower resistance: re-use what's already been designed and which works well within the fossil project. i'd love to see what you have when you're ready to post it, though. (i recall you(?) posting about this in the fossil forum before - feel free to announce your project there when you're ready.)

> As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.

What else would one call a "container of cards"? :)

Re: Fossil Chat

#133

Post by sgbeal »

bch wrote: post #118
sigzero wrote: post #12

Earlier quoted context omitted.

That probably had a lot to do with it I am sure.

> Ah, due to (who would've thunk) the SQLite connection. The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing suppor…

> The ties are interesting and deep.

Brad! You're alive! In case you hadn't heard: libfossil was recently revived, has been brought up to date with regards to SHA3 hashes, and got both "update" and "revert" APIs within the past week or two. The "last" major day-to-day feature it's missing is merge. We have the merge algo (it's used by update), but not yet the equivalent of the merge command. Your account is still active on the repo (https://fossil.wanderinghorse.net/r/libfossil).

Re: Fossil Chat

#134

Post by bachmeier »

dahart wrote: post #124
bachmeier wrote: post #119

Earlier quoted context omitted.

> There is no need to speak negatively about the behaviour of other players I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburge…

What history, exactly, is being preserved? If I fix a bug before I commit, then I’m okay. If I commit the bug, then commit the fix, then squash, all locally on my own machine before I push anything, I’m “lying”? You don’t want the ability to edit your own mistakes before showing them to other people, even if you find them before you push? Fossil is not capturing my pre-commit keystrokes, so I can write code and delet…

I think (a) all of this was explained clearly in the post by SQLite (Fossil creator), and (b) you're overly sensitive to a disagreement about the definition of terms. I agree with him. You don't. That's fine - no kittens will be put to death depending on who is right.

Re: Fossil Chat

#135

Post by emodendroket »

mscrnt wrote: post #121
emodendroket wrote: post #20

Earlier quoted context omitted.

It seems to me like you’d want it to be obviously way superior for some reason to go so far away from the herd.

You’d forsake an improvement for the sake of following the rest of the cattle? Have you used it, yet, to see if it sufficiently meets your way superior standard to break free from the herd?

Well yeah because git is, I find, good enough that I don’t have much desire to experiment with other SCM tools. Some people love customizing every part of their tool chain but to me it’s better to stick with something familiar with things like that so I can focus on solving my actual problem.

Re: Fossil Chat

#136

Post by bch »

sgbeal wrote: post #133
bch wrote: post #118

Earlier quoted context omitted.

> Ah, due to (who would've thunk) the SQLite connection. The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing suppor…

> The ties are interesting and deep. Brad! You're alive! In case you hadn't heard: libfossil was recently revived, has been brought up to date with regards to SHA3 hashes, and got both "update" and "revert" APIs within the past week or two. The "last" major day-to-day feature it's missing is merge. We have the merge algo (it's used by update), but not yet the equivalent of the merge command. Your account is still act…

I’ll ping you offline. I’d love to get back to that with you. Also enjoy seeing your comments all over this article :)

Re: Fossil Chat

#137

Post by mscrnt »

jayd16 wrote: post #107
mgreenleaf wrote: post #10

Earlier quoted context omitted.

I think the idea is so that core developers have a quick way to chat with one another over design ideas w/o needing to register or setup other infrastructure, then move the best over to the permanent forum record or wiki. Then the core members don't need to have a dedicated channel somewhere else. If they did, then that would be another inbox to check; instead they can check the fossil chat when they are on the proje…

>Then the core members don't need to have a dedicated channel somewhere else. But isn't that "a replacement"?

Not a replacement inasmuch as it's not a standalone chat client to be used by disparate users for various reasons. It's a chat client for developers of a given project to convene discussion about work going on in that repository at that point in time. So where Discord, for example, is for anyone to setup a server to discuss anything; Fossil chat is for devs working on projects that already use Fossil to convene discussions pertaining to that repository. You won't setup a Fossil instance just to use as a chat client—because it's not intended as a replacement or competitor for —but if your project already uses Fossil, now you can keep your dev-related chat in-house.

Re: Fossil Chat

#138

Post by edwinyzh »

sgbeal wrote: post #85
supportlocal4h wrote: post #81

Earlier quoted context omitted.

Heh. Building an scm is a great way to become so busy you don't have time for your actual work. Building a db is another great way. If I could be so unproductive...

> If I could be so unproductive... It goes much further than that... When one views a fossil-hosted forum post from the main fossil site or sqlite's site, they are looking at... - A forum post rendered by software Richard wrote. - Piped out to you via an HTTP server he wrote. - Served from an SCM he wrote. - Stored on a database package he wrote. - All coded in a text editor he wrote. Complete vertical integration. H…

Now I'm interested in the text editor Dr. wrote!

Re: Fossil Chat

#139

Post by mscrnt »

dahart wrote: post #130
BeetleB wrote: post #104

Earlier quoted context omitted.

First, it sounds like you're looking for squash - not rebase. This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways. In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar. Looking at this subthread: Wow! People really get tr…

I guess you’re referring to me, and I guess it’s fair. It has nothing to do with git though, I’m triggered when it comes to arguments that I feel like aren’t being made in good faith. Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.

You shun the secrets-leaking commit: https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

Re: Fossil Chat

#140

Post by [deleted] »

dahart wrote: post #130
BeetleB wrote: post #104

Earlier quoted context omitted.

First, it sounds like you're looking for squash - not rebase. This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways. In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar. Looking at this subthread: Wow! People really get tr…

I guess you’re referring to me, and I guess it’s fair. It has nothing to do with git though, I’m triggered when it comes to arguments that I feel like aren’t being made in good faith. Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.

[deleted]
Post reply on HN