wyoung2

> switch-branch-in-place is seen as some kind of flaw

You're conflating two separate concepts:

1. Git's default of commingled repo and and working/checkout directory

2. Switch-in-place workflow encouraged by #1

Fossil doesn't do #1, but that doesn't prevent switch-in-place or even discourage it. The hard separation of repo and checkout in Fossil merely encourages multiple separate long-lived checkouts.

A common example is having one checkout directory for the active development branch (e.g. "trunk" or "master") and one for the latest stable release version of the software. A customer calls while you're working on new features, and their problem doesn't replicate with the development version, so you switch to the release checkout to reproduce the problem they're having against the latest stable code. When the call ends, you "cd -" to get back to work on the development branch, having confirmed that the fix is already done and will appear in the next release.

Another example is having one checkout for a feature development branch you're working on solo and one for the team's main development branch. You start work from the team's working branch, realize you need a feature branch to avoid disturbing the rest of the team, so you check your initial work in on that branch, open a checkout of that new branch in a separate directory and continue work there so you can switch back to the team's working branch with a quick cd if something comes up. Another team member might send you a message about a change needed on the main working branch that you're best suited to handle: you don't want to disturb your personal feature branch with the work by switching that checkout in place to the other branch, so you cd over to the team branch checkout, do the work there, cd back, and probably merge the fix up into your feature branch so you can work with the fix in place there, too.

These are just two common reasons why it can be useful to have multiple long-lived checkouts which you switch among with "cd" rather than invalidate build artifacts multiple times in a workday when switching versions.

Git can give you multiple long-lived working checkouts via git-worktree, but according to the Internets it has several well-known problems. Not being a daily Git user, I'm not able to tell you whether this is still true, just that it apparently has been true up to some point in the past.

Since no one is telling me those issues with git-worktree are all now fixed, it remains a valid point of comparison in the fossil-v-git article.

You’re not addressing the list of problems resulting from the use of this tacked-on feature.

Also, Git continues to be taught with the switch-in-place method by default.

I’m not saying it is impossible to get a Fossil-like workflow with Git, just that there are consequences from that not being the default.

> Not sure I understand the problem. If I lock fileX and go to lunch, then I own the lock on that file while I’m out to lunch.

And if you go on vacation for two weeks instead?

> I’d guess not one user in 100.000 uses git decentralized

I understand your sentiment, but the denominator in that fraction is probably much lower than your guess.

Consider even simple cases like the disconnected laptop case. You may work at a small office with only local employees, and so you have one central "blessed" repo, but if one person locks a file and then goes off to lunch, working on the file while at the restaurant, you still have a CAP problem:

CA: Because the one guy with a laptop went off-network, you have no full quorum, so no one can use the repo at all until he gets back and rejoins the network. (No practical DVCS does this, but it's one of the options, so I list it.)

CP: When the one guy went off to lunch, we lost the ability to interact with his lock, and that will continue to be the case until he gets back from lunch. Also vice versa: if someone still at the office takes out a lock, the guy off at lunch doesn't realize there is lock, so he could do something bad with the "locked" file. (This is the mode DVCSes generally run in by default.)

AP: No locking at all, thus no consistency, thus your original problem that inspired the wish to have file locking.

Yes, I cover that option for Fossil at the end of the pointed-to document. I did it in terms of Makefiles rather than commit hooks, but whichever...

> By the way, the "one checkout per repository" is not strictly true.

You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git.

I suspect this is because git-worktree is a relatively recent feature of Git (2.5?) so most tutorials aren't written to assume use of it, so most tools don't focus on making it work well, so bugs and weaknesses with it don't get addressed.

Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place.

> test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow.

That just brings you back to the problems you buy when separating commit from push, which we cover elsewhere in that doc, primarily here: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

> This is not biased in any way

Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top.

Here's the direct link for that particular point:

https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

Now, if you want to debate section 2.2 on its merits, we can get into that.

> you can’t claim something to be “efficient” when it’s doing many different things

We can when all of that is in a single binary that's 4.4 MiB, as mine here is.

A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient."

But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading.

> git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm).

It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there.

On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself.

If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.)

> This page needs to be rewritten to simply list the differences in neutral language.

We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it.

> unnecessary epithets like “caused untold grief for git users”

You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language.

> I don’t want something that tries to do many different things all at once.

Not a GitHub user, then?

> Hey, are you a fossil dev?

I have commit access, yes, but mainly I work on the docs.

> Does fossil now have any kind of email support built in to the ticket manager?

Yes. It was added in support of the forum feature last year, but it also applies to several other event types: https://fossil-scm.org/fossil/doc/trunk/www/alerts.md

> one of the devs said to just write a script to monitor the fossil rss feed

Probably me. :)

> seemed like a baroque and fragile (and time-consuming) solution.

A dozen lines of Perl; easy-peasy. That and a pile of CPAN modules, but that's easily fetched with `cpanm`.

> the mv/rm behavior -- affecting the file on disk as well as the repository

The default you're referring to was changed a few years ago: the old `--hard` option is now the default.

Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger.

In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. (https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki)

You're making bisects, cherry-picks, and backouts harder by squashing history like that.

We cover this and more in the Fossil project document "Rebase Considered Harmful": https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md

> Git is a complex tool because it’s tackling a complex problem.

Fossil tackles much the same sort of problem, yet it's far simpler to use.

Most of Git's problems are due to purposeful choices, but they're design choices, not inherent aspects of how a DVCS must behave.

We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS.

I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences.

We discussed this deeply on the Fossil forum: https://www.fossil-scm.org/forum/forumpost/2afc32b1ab

We came to no easy answers, because there aren't any. You only get a choice of which problems to accept.

There is zero doubt in my mind that it's Github that "made" Git. Without it, it would be just another one of many DVCSes. Git's value isn't inherent, it's all down to network effects.

Which is why there are dozens of Git front-ends, fragmenting the market, reducing the benefit of cross-training within a team. "Oh, you can't do that in your TortoiseStudioCodeThingy? I just right-click and select Frobnicate File, and it fixes all that!"

Thus editor wars, language wars...

Alternative: a tool like Fossil where the CLI is sensible from jump so the whole team doesn't replace it with something better, uniquely per team member.

The simplest way to do that is to just use it for a local project. Say, you local ~/bin directory, containing your local scripts, or your editor's config files that you want sync'd everywhere, or a novel you're writing on the side.

If you're like me, you'll find yourself increasingly wonder, "Why would I put up with Git any time I'm not forced to by some outside concern?"

Not at all. There's a lot of nice stuff that falls out of Fossil's integration of these features, things which you don't get when you lash them up from separate parts.

For example, if I have a check-in comment "Fixes [abcd1234]" I get an automatic link from that check-in comment to ticket abcd1234 from the web UI's timeline view. If I then close that ticket, the comment in the timeline view is rendered in strikethrough text, so I don't have to visit the ticket to see that it's closed.

Similarly, a built-in forum means the project's developers can discuss things with easy internal reference to wiki articles, tickets, checkins...

A recent feature added to Fossil is the ability to have a wiki article bound to a particular check-in or branch, so that whenever someone views that artifact in the web UI, they get a link to the ongoing discussion about it. This is useful when you have more to say about the check-in or branch than can reasonably fit into a comment box. This solves a common problem with experimental features, where you want to discuss it and evolve the idea before it's merged back into the parent branch.

Fossil's user management features are also highly helpful.

    http://fossil-scm.org/fossil/doc/trunk/www/caps/

With raw Git (no Github, GitLab, etc.) it's pretty much all-or-nothing, but with Fossil, you can say "this user can do these things, but not these other things." Thus you can set up a public project, giving anonymous users the ability to file tickets and read the forum but not make check-ins.

These features are as seductive as what Github, GitLab, BitBucket, etc. add to Git, but whereas those are all proprietary services with some of the roach hotel nature to them, with Fossil, you clone the repo and now you've got all of that locally, too. If the central repo goes down, you can stand your local clone up as a near-complete replacement for it.

It's not 100% because Fossil purposely doesn't clone a few things like the user table, for security reasons. You can build a new user table from the author names on the check-ins, though.

You can, though I suspect the OP's focus on speed means you'd want to turn off Fossil's autosync feature, which makes it operate more like Git: checkins go only the local repository initially, and then you must later explicitly push them to the repo you cloned from.

This is why Subversion was "slow": your local working speed was gated by the speed of the central repo, which could be slow if it was under-powered or overloaded, as was common with the free Subversion hosts of the day. At least with Git, you can batch your local changes and push them all at some more convenient time, such as when you were going off for a break anyway.

> Another thing Git does not and cannot even attempt to do - file locking.

That's a seriously hard problem for a DVCS if you're serious about the "D".

This topic turned into [the single longest thread in the history of the Fossil forum](https://www.fossil-scm.org/forum/forumpost/2afc32b1ab) because it drags in the CAP theorem and all of the problems people run into when they try to have all three of C, A, and P at the same time.

To the extent that Fossil based projects are usually more centralized than Git ones, Fossil has a better chance of solving this, but I'm still not holding my breath that Fossil will get what a person would naively understand as file locking any time soon.

> Word documents (documentation), Photoshop files (source of graphics), PNGs (icons in webapps), and so on.

You want to avoid putting such things into a VCS anyway, because it [bloats the repo size](https://fossil-scm.org/fossil/doc/trunk/www/image-format-vs-...). I wrote that article in the context of Fossil, but its key result would replicate just as well under Git or anything else that doesn't do some serious magic to avoid the key problem here.

Instead of Word files, check in Markdown or [FODT](https://en.wikipedia.org/wiki/OpenDocument_technical_specifi...). (Flat XML OpenDocument Text.) Or with Fossil, put the doc in the wiki.

Instead of PNG, check in BMP, uncompressed TIFF, etc., then "build" the PNG as part of your app's regular build process.

This has the side benefit that when you later change your mind on the parameters for the final delivered PNGs, you can just adjust the build script, not check in a whole new set of PNGs. My current web app has several such versions: 8-bit paletted versions from back before IE could handle 24-bit PNG, then matted 24-bit PNGs from the days when IE couldn't handle transparency in PNG, and finally the current alpha-blended 24-bit PNGs. It'd have been better if I'd checked in TIFF originals and built deliverable PNGs at each step.

> Git is hard for idiots imo, and there are a lot of us

Yes, thus https://xkcd.com/1597/

I find myself saying "git reset --hard origin/" and such with disturbing frequency.

Both are examples of "I give up; it's faster to start over." This is not what I want in a DVCS.

> But why prioritize portability over better functionality at all?

It's not just about portability, or even primarily. It's simply good application layering to put the DB code behind a layer. Intermingling SQL code in your application logic is just as bad as intermingling GUI code in your core app logic.

But even that aside, we haven't felt the lack from putting such code a single function call layer away. I suppose it may give us a slight amount of pause when we consider whether it's worth creating another function in that helper library, but that's probably a good thing. If we decide we can get our work done by calling one of the existing functions, then why write yet another DB access function?

Example: if a table is known to have at most 5 rows, and the query that would allow the DB to return just the one we actually want is complicated, and it's almost never called, why not call the existing "SELECT all" one and iterate over the rows? The performance hit of being inefficient will be immeasurable.

> Why did you move databases so often?

That's once every 8 years on average. A lot changes in the computing world over that span.

The first change did coincidentally happen about 8 years after the company was founded, and it was because much better DBMS tech became available to us, within the constraints we had on choosing.

That DBMS lasted us for the next 14 years. By that time, enough had changed in the computing world that it was worth swapping again. The new one runs about twice as fast, takes far less code space, and is simpler to use all around than the prior one.

We'd have to switch again this year in order to maintain the mean of once every 8 years. My sense is that this is more likely a nonlinearly increasing growth curve, so that the next switch will be closer to 20 years than 14, if it happens at all.

$500 is still less than the one-time price of Photoshop back when it was sold in boxes. Photoshop is well worth $120/year if you're able to use a big enough fraction of its power.

One way to look at it, then, is that you don't use enough of what Photoshop can do to be worth it, so you can stick with whatever simpler tool you prefer and save the money. Another option, though, is to realize that there's a lot of power there to be had, and it's worth spending the time to learn to harness it.

I put it that way because I keep coming across people who talk about their favorite image editor as "just as good as Photoshop" for their purposes while they clearly have no idea what all Photoshop can do. Here's a tutorial I did for Photoshop once that probably can be done only in Photoshop:

    https://photo.stackexchange.com/a/57233/4141

Now, I don't expect you to need to retexture pictures of couches, but I'll bet if you read through that tutorial, you'll be surprised that such things even could be done in off-the-shelf software. Then realize that I'm not even a full-time professional in graphical arts. If I can pull off such tricks, what can a real expert do with it?

By the way, Lightroom was another $120 or so for the initial license when it was last sold in boxes.

Then there's all the upgrades, which you also now get as part of the subscription.

Your $50 just isn't apples-to-apples.

That's the thing: it's super tempting to use nonstandard features. On our last SQL transition, we were most bitten by use of data types the new DBMS didn't support and by changes in the way "standard" text data types behaved between the two. (Just as GitLab was, on that last one.)

That's why I don't regret putting all of our SQL behind that DB layer: to port to the new DBMS, we just had to rewrite parts of that layer, rather than go on a hunt through the whole application for one-off SQL calls, as would probably occur if we didn't enforce this discipline.

The app I’ve been working on for the past 24 years is currently on its third DBMS, and I would be unwilling to bet on whether it’s on its last DBMS.

There is zero SQL code in our app above a very low level. All high-level code calls through a DB API, and all SQL code is behind that abstraction layer.

That said, each one of these transitions was a “pull up stakes and move” kind of thing. We never tried to support multiple back-ends at once. So on those grounds, I think this is probably a good move for GitLab.

I also found Bézier curve drawing more straightforward in CorelDRAW! than in Illustrator. I made the shift so long ago that I can’t remember the specifics, but the main difference was that Corel let you more easily switch among the modes for a point: cusp vs. smooth, split handles vs. symmetric, move mode vs. draw mode, etc.

There’s a learning curve you can get past that makes this difference go away, and it’s mainly down to grooving the modifier keys into finger memory. Once you stop consciously thinking “hold Command to switch from pen to white arrow mode” and such, you can work just as fast in Illustrator.

Illustrator helps teach you the modifier keys by changing the cursor as you hold down the modifiers. So, the next time you get stuck, just press them down one at a time until you get a cursor that looks like it should do what you want and see if it helps.

> load several photos that I shot in a burst and then let me cleanly flip back and forth between them to pick the best one

Yes, Photoshop does have that, though you do it through Bridge or Lightroom instead of in the same app. (Bridge is a companion app to Photoshop in all its versions, and Lightroom is bundled with it in most Creative Cloud plans.)

Lightroom is famous for not being super-fast in image import, so you might not find it fit for purpose. It has a bunch of compensating value that makes putting up with this worthwhile for many of us. I’ve tried a few of the alternatives that claim to be Lightroom killers, and they weren’t even close on several key measures.

The latest one I tried couldn’t do hierarchical keyword management and would reliably crash every hour or so, for example.

> they should adopt standard browser zoom shortcuts

Ah, irony; browsers got those shortcuts from Photoshop! Early browsers didn’t have those features at all. It was probably the Mac browsers that made this a standard, since Mac apps more reliably support those shortcuts, since Photoshop and MacOS have such a long and close shared history.

(Okay, the shifted variants aren’t in Photoshop, but the other three are.)

> I will never be able to afford Photoshop

Seriously? It’s $10/month on the Photography Plan, and you get Lightroom and some online storage in the same bundle as well:

    https://www.adobe.com/creativecloud/photography.html

I get that $120/year is significant, but it doesn’t take much payback in terms of time saved to make it worthwhile. If you can’t squeeze $120/year of use value out of Photoshop and Lightroom, you probably don’t do enough image editing and photography to make any photo app worth buying.

There are two classes of algorithms you can use to solve that problem: zero-knowledge proofs and Password Authenticated Key Exchanges (PAKE):

    https://en.m.wikipedia.org/wiki/Zero-knowledge_proof
    https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement

In both, the client proves that it knows the password without ever sending it over the wire. The server also doesn’t store it in plaintext.

In the algorithm I’m most familiar with (SRP6a) the plaintext password never leaves the client machine either on initial signup or on later password-based authentication, and what does transit the wire can be used neither to recover the password nor to replay the login attempt. You cannot break into the account just by passively watching the messages go back and forth.

    https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol

One of the posts down-thread mentioned SCRAM, which I believe qualifies as a zero-knowledge proof algorithm, not a PAKE, but that’s about all I know about it.

https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Au...

One nice thing that falls out of a PAKE algorithm, as opposed to a zero-knowledge proof, is that you get a cryptographic key on both sides (thus the “key exchange” part of the acronym) that the peers can use with a symmetric encryption algorithm to communicate with each other. This then lets you construct things like TLS-SRP, which is a variant of TLS (ne SSL) that uses SRP to get the symmetric key instead of X.509 certificates and an entirely different key exchange algorithm:

    https://en.m.wikipedia.org/wiki/TLS-SRP

Incidentally, the use of this sort of algorithm is why so many web sites now prompt for the user name and password on separate screens. There’s usually at least a two-way exchange involved where the user name goes to the server, which provides some bit of cryptographic hoo-hah, which then lets the client prove to the server in a separate exchange that it knows the password. This goes against old guidance to ask for both at once and to reject the login if either the user name or password are incorrect, which avoids giving an attacker a way to probe for valid user names. We lose that in the name of greater security goals.

I've got a headless UDP multicast networking app in F# that runs just fine on Windows, macOS, and Linux. If that's not miles from Microsoft's traditional core app market, I don't know what is.

> I don't imagine I'd want to deal with it writing WPF / UWP things though where language support is more important

As the article points out, there never has been any visual forms designer type stuff for F#, so if you're writing a GUI app with F#, it's best to wrap it in a C# shell anyway.

Which is fine, because you wanted to separate your core application logic from the GUI anyway, right?

> I might just write the business logic in F# and glue things together with C#

It's a perfectly reasonable way to go.

The only difficulty is that it simplifies things if you don't try to do all the fancy FP stuff at the boundary between the F# and C# parts of the app. While there are ways to pass, say, a tuple from F# to C# and cope with it on the C# side, it's better to limit types at this interface to things both languages support as first-class citizens: arrays, objects, simple scalars, etc.

RHEL 7 took 6 months to go from the first beta to the first release. Don’t hold your breath.