8 ms·

I'm a big fan of Fossil myself. But the SQlite people have something that I don't really have within the teams I operate : the authority to dare and speak out

by neals 9y ago

I'm a big fan of Fossil myself. But the SQlite people have something that I don't really have within the teams I operate : the authority to dare and speak out against Git and not be laughed away like a hipster that is just trying to be different.

matt_wulfeck 9y ago
Git is a use-case that is excellent for 90% of development. Sqlite is just an example where the use-case isn't necessarily ideal, not an indicator that it's "better" than git.
- bch 9y ago
  I’m a fossil fan. I’d say that git is fine for 90% of development (or some arbitrarily large number), but so is fossil. I don’t even think that SQLite-in-git would necessarily be a deal-breaker that couldn’t be worked around (drh ‘sqlite can chime in here). The whole space (from personal projects to global collaboration) is diverse enough that there’s no talking about “better” without qualifying the situation, either. Fossil is good for a large subset of work that can benefit from source control management, regardless of git. What git definately has is 1) scaleabilty, which is probably of no consequence for 99% of the cases it is employed 2) network effect, for better AND worse
  - nebulous1 9y ago
    > drh ‘sqlite can chime in here He already has > With Git, it is very difficult to find the successors (decendents) of a check-in ... This is a deal-breaker, a show-stopper.
    - deleted 9y ago
      [deleted]
    - AstralStorm 9y ago
      Someone still thinks in the single main branch mode. It is sometimes the main case but definitely not in git world. This operation is not easy in any DAG. It involves: - find all or desired branch tips - walk backwards until hitting tge desired checkin - memoize already seen parents to not walk them multiple times
  - bzbarsky 9y ago
    Amusingly enough, git's scaleability is also not that great (e.g. worse than mercurial last I checked). The network effects are there, though.
    - AstralStorm 9y ago
      Please provide the source about scalability. Also what kind of scalability?
      - bzbarsky 9y ago
        Scalability to large numbers of files and large numbers of changesets. For the large number of files one https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... is one source. There's some earlier discussion of the same issue at https://news.ycombinator.com/item?id=3549679 https://news.ycombinator.com/item?id=3549679 that goes into some technical details. There has been some work on git since then to address some of those issues (e.g. see https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g... ) but it's not clear to me that it helped enough to catch up to where Mercurial is for large repos. For large numbers of changesets, just try running "log" or "annnotate" on any file with a long history in git. I just did this simple experiment: 1) hg clone https://hg.mozilla.org/mozilla-central/ https://hg.mozilla.org/mozilla-central/ 2) git clone https://github.com/mozilla/gecko-dev.git https://github.com/mozilla/gecko-dev.git 3) (cd mozilla-central && time hg log dom/base/nsDocument.cpp) 4) (cd gecko-dev && time git log dom/base/nsDocument.cpp) It's not quite apples to apples because the git repo there has some pre-mercurial CVS history in it. But note that I'm not even using --follow for git and the file _has_ been renamed after the mercurial repo starts, so git is actually finding fewer commits than mercurial is here. Anyway, if I do the above log calls a few times to make sure the caches are warm, I end up seeing times in the 8s range for git and the 0.8s range (yes, 10x faster) for mercurial. That all said, most repos do not have millions (or even hundreds of thousands) of changesets or files. So the scalability problems are not problems for most users of either VCS.
- pmarreck 9y ago
  I have never once had to use the missing feature that was a dealbreaker for the SQLite guys (find the descendants of an arbitrary commit). I have no idea what they're doing if they super depend on something like that.
tetha 9y ago
What the hell, speaking against git makes you a hipster now? I was called a hipster for proposing git over CSV and SVC.
- adamcw 9y ago
  As I'm not familiar with those, I have to ask: did you mean CVS and SVN?
  - tetha 9y ago
    Ack. I'm damn sorry, I just had a fully botched prod-update from hell and I'm on tilt. Yes. CVS and SVN. The old and ugly ones.
    - adamcw 9y ago
      Hahah. Nothing to be sorry for, I was just curious. There are enough source systems out there, I wouldn't be surprised if they were a few I hadn't heard of.
    - hermitdev 9y ago
      You want old, ugly, slow, pain-in-the-ass and proprietary,? Try ClearCase. Expensive. Drain on productivity (all commits were individual file based, meaning it was extraordinarily easy to miss a change; also had no concept of an ignore, so really easy to miss adding a new file). Also, very. fucking. slow. A moderately sized project (or VOB in clearcase terminology) could take an hour to update. I've probably lost a year of my life waiting for clearcase to complete. Also, it had a habit of just royally fucking up even trivial merges (dropping braces in C++ code, for example, or ignoring whitespace changes in python code for another).
      - lokedhs 9y ago
        I've never used Clearcase, but I worked for Sun around 2000 and one of the things I did was analysing kernel dumps of Solaris. If we saw the Clearcase kernel module you can be sure that that was going to be the root cause of the crash. That thing seemed to really terrible, and it wouldn't surprise me if the rest of the product was as bad. I don't know if things have changed now, but to use Clearcase you needed a kernel module that provided a special filesystem that you did your work against.
cies 9y ago
Hipster source code management? See this Rust project: https://pijul.org https://pijul.org https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html A bit like DARCS (also very hipster, in Haskell and has some math behind it), but then fast. https://pijul.org/model/#efficient-algorithms https://pijul.org/model/#efficient-algorithms https://pijul.org/faq/ https://pijul.org/faq/ Oh and it uses a cool hi-perf storage lib (also in Rust, by the same devs): https://nest.pijul.com/pijul_org/sanakirja https://nest.pijul.com/pijul_org/sanakirja
- peatmoss 9y ago
  Darcs was also prior art (certainly the first DVCS I ever encountered), which makes me more inclined to call them innovative than hipster :-)
  - cies 9y ago
    That would make Haskell innovative instead of hipster as well.. :)
    - peatmoss 9y ago
      Woah woah woah, let’s not get ahead of ourselves! :-)
- hinkley 9y ago
  Pijul lets you describe your edits after you’ve made them, instead of beforehand. Pardon my French, but about fuckin time. On a big product, forensics matter. Not day to day, but often enough and if your metadata is rotten then you’re left with the oral history of the project as your only guide. And even that may not exist, depending on project structure.
  - pyre 9y ago
    Git has something similar called git-notes, but at the time I tried using it, it was really early-days. No idea how support is working for that now. You could also make an annotated tag, which has it's own "commit message", but it will show up with all other tags. [1] https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes
bigbadgoose 9y ago
We use zip files distributed and synced by blockchain across BTC and Ether
- johnhenry 9y ago
  I know this is a joke, but have you checked out mango? https://github.com/axic/mango https://github.com/axic/mango
  - bigbadgoose 9y ago
    Lol, i mean, it's within the realm of plausibility. My secret sauce is the zipping. The SHA integrity and the zippy bits are decentralized separately and n-matrix distributed across multiple cryptos using a randomized forward time arrow only strategy. so, pretty psicc.
- nickpeterson 9y ago
  You should probably form a corp.
eddieh 9y ago
I recently tried to speak out against GitFlow...that was a mistake on my team.
- mythrwy 9y ago
  I would have backed you up on that.
  - e12e 9y ago
    Why?
- pdfernhout 9y ago
  See for example: http://endoflineblog.com/gitflow-considered-harmful http://endoflineblog.com/gitflow-considered-harmful "I remember reading the original GitFlow article back when it first came out. I was deeply unimpressed - I thought it was a weird, over-engineered solution to a non-existent problem. I couldn't see a single benefit of using such a heavy approach. I quickly dismissed the article and continued to use Git the way I always did (I'll describe that way later in the article). Now, after having some hands-on experience with GitFlow, and based on my observations of others using (or, should I say more precisely, trying to use) it, that initial, intuitive dislike has grown into a well-founded, experienced distaste. In this article I want to explain precisely the reasons for that distaste, and present an alternative way of branching which is superior, at least in my opinion, to GitFlow in every way." And a summary of an alternative proposed there: http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow http://endoflineblog.com/oneflow-a-git-branching-model-and-w... "As the name suggests, OneFlow's basic premise is to have one eternal branch in your repository. This brings a number of advantages (see below) without losing any expressivity of the branching model - the more advanced use cases are made possible through the usage of Git tags. While the workflow advocates having one long-lived branch, that doesn't mean there aren't other branches involved when using it. On the contrary, the branching model encourages using a variety of support branches (see below for the details). What is important, though, is that they are meant to be short-lived, and their main purpose is to facilitate code sharing and act as a backup. The history is always based on the one infinite lifetime branch."
lsaferite 9y ago
So, being a fan of Fossil would make you a Hippster then, no? O_o I'll find my way out.
- lsaferite 9y ago
  So is it a lack of humor or just missing the joke that's getting the negative score?
krylon 9y ago
At work, I use fossil to manage my repository of scripts that I edit and use on different machines. (Strictly speaking, that could be done without an SCM, but I find it more convenient this way.) On Windows, that fact that fossil comes as a single statically-linked executable that works without any special installation procedure[0] is really nice. Also, I have to appreciate the builtin Wiki. I use it to keep a kind of diary of what I did and why, as well as gather helpful links I have come across over time. [0] Other than putting the executable somewhere on your %PATH%, of course.

by neals 9y ago

matt_wulfeck 9y ago

Git is a use-case that is excellent for 90% of development. Sqlite is just an example where the use-case isn't necessarily ideal, not an indicator that it's "better" than git.

bch 9y ago
I’m a fossil fan. I’d say that git is fine for 90% of development (or some arbitrarily large number), but so is fossil. I don’t even think that SQLite-in-git would necessarily be a deal-breaker that couldn’t be worked around (drh ‘sqlite can chime in here). The whole space (from personal projects to global collaboration) is diverse enough that there’s no talking about “better” without qualifying the situation, either. Fossil is good for a large subset of work that can benefit from source control management, regardless of git. What git definately has is 1) scaleabilty, which is probably of no consequence for 99% of the cases it is employed 2) network effect, for better AND worse
- nebulous1 9y ago
  > drh ‘sqlite can chime in here He already has > With Git, it is very difficult to find the successors (decendents) of a check-in ... This is a deal-breaker, a show-stopper.
  - deleted 9y ago
    [deleted]
  - AstralStorm 9y ago
    Someone still thinks in the single main branch mode. It is sometimes the main case but definitely not in git world. This operation is not easy in any DAG. It involves: - find all or desired branch tips - walk backwards until hitting tge desired checkin - memoize already seen parents to not walk them multiple times
- bzbarsky 9y ago
  Amusingly enough, git's scaleability is also not that great (e.g. worse than mercurial last I checked). The network effects are there, though.
  - AstralStorm 9y ago
    Please provide the source about scalability. Also what kind of scalability?
    - bzbarsky 9y ago
      Scalability to large numbers of files and large numbers of changesets. For the large number of files one https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... is one source. There's some earlier discussion of the same issue at https://news.ycombinator.com/item?id=3549679 https://news.ycombinator.com/item?id=3549679 that goes into some technical details. There has been some work on git since then to address some of those issues (e.g. see https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g... ) but it's not clear to me that it helped enough to catch up to where Mercurial is for large repos. For large numbers of changesets, just try running "log" or "annnotate" on any file with a long history in git. I just did this simple experiment: 1) hg clone https://hg.mozilla.org/mozilla-central/ https://hg.mozilla.org/mozilla-central/ 2) git clone https://github.com/mozilla/gecko-dev.git https://github.com/mozilla/gecko-dev.git 3) (cd mozilla-central && time hg log dom/base/nsDocument.cpp) 4) (cd gecko-dev && time git log dom/base/nsDocument.cpp) It's not quite apples to apples because the git repo there has some pre-mercurial CVS history in it. But note that I'm not even using --follow for git and the file _has_ been renamed after the mercurial repo starts, so git is actually finding fewer commits than mercurial is here. Anyway, if I do the above log calls a few times to make sure the caches are warm, I end up seeing times in the 8s range for git and the 0.8s range (yes, 10x faster) for mercurial. That all said, most repos do not have millions (or even hundreds of thousands) of changesets or files. So the scalability problems are not problems for most users of either VCS.
pmarreck 9y ago
I have never once had to use the missing feature that was a dealbreaker for the SQLite guys (find the descendants of an arbitrary commit). I have no idea what they're doing if they super depend on something like that.

tetha 9y ago

What the hell, speaking against git makes you a hipster now? I was called a hipster for proposing git over CSV and SVC.

adamcw 9y ago
As I'm not familiar with those, I have to ask: did you mean CVS and SVN?
- tetha 9y ago
  Ack. I'm damn sorry, I just had a fully botched prod-update from hell and I'm on tilt. Yes. CVS and SVN. The old and ugly ones.
  - adamcw 9y ago
    Hahah. Nothing to be sorry for, I was just curious. There are enough source systems out there, I wouldn't be surprised if they were a few I hadn't heard of.
  - hermitdev 9y ago
    You want old, ugly, slow, pain-in-the-ass and proprietary,? Try ClearCase. Expensive. Drain on productivity (all commits were individual file based, meaning it was extraordinarily easy to miss a change; also had no concept of an ignore, so really easy to miss adding a new file). Also, very. fucking. slow. A moderately sized project (or VOB in clearcase terminology) could take an hour to update. I've probably lost a year of my life waiting for clearcase to complete. Also, it had a habit of just royally fucking up even trivial merges (dropping braces in C++ code, for example, or ignoring whitespace changes in python code for another).
    - lokedhs 9y ago
      I've never used Clearcase, but I worked for Sun around 2000 and one of the things I did was analysing kernel dumps of Solaris. If we saw the Clearcase kernel module you can be sure that that was going to be the root cause of the crash. That thing seemed to really terrible, and it wouldn't surprise me if the rest of the product was as bad. I don't know if things have changed now, but to use Clearcase you needed a kernel module that provided a special filesystem that you did your work against.

cies 9y ago

Hipster source code management? See this Rust project: https://pijul.org https://pijul.org https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html A bit like DARCS (also very hipster, in Haskell and has some math behind it), but then fast. https://pijul.org/model/#efficient-algorithms https://pijul.org/model/#efficient-algorithms https://pijul.org/faq/ https://pijul.org/faq/ Oh and it uses a cool hi-perf storage lib (also in Rust, by the same devs): https://nest.pijul.com/pijul_org/sanakirja https://nest.pijul.com/pijul_org/sanakirja

peatmoss 9y ago
Darcs was also prior art (certainly the first DVCS I ever encountered), which makes me more inclined to call them innovative than hipster :-)
- cies 9y ago
  That would make Haskell innovative instead of hipster as well.. :)
  - peatmoss 9y ago
    Woah woah woah, let’s not get ahead of ourselves! :-)
hinkley 9y ago
Pijul lets you describe your edits after you’ve made them, instead of beforehand. Pardon my French, but about fuckin time. On a big product, forensics matter. Not day to day, but often enough and if your metadata is rotten then you’re left with the oral history of the project as your only guide. And even that may not exist, depending on project structure.
- pyre 9y ago
  Git has something similar called git-notes, but at the time I tried using it, it was really early-days. No idea how support is working for that now. You could also make an annotated tag, which has it's own "commit message", but it will show up with all other tags. [1] https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes

bigbadgoose 9y ago

We use zip files distributed and synced by blockchain across BTC and Ether

johnhenry 9y ago
I know this is a joke, but have you checked out mango? https://github.com/axic/mango https://github.com/axic/mango
- bigbadgoose 9y ago
  Lol, i mean, it's within the realm of plausibility. My secret sauce is the zipping. The SHA integrity and the zippy bits are decentralized separately and n-matrix distributed across multiple cryptos using a randomized forward time arrow only strategy. so, pretty psicc.
nickpeterson 9y ago
You should probably form a corp.

eddieh 9y ago

I recently tried to speak out against GitFlow...that was a mistake on my team.

mythrwy 9y ago
I would have backed you up on that.
- e12e 9y ago
  Why?
pdfernhout 9y ago
See for example: http://endoflineblog.com/gitflow-considered-harmful http://endoflineblog.com/gitflow-considered-harmful "I remember reading the original GitFlow article back when it first came out. I was deeply unimpressed - I thought it was a weird, over-engineered solution to a non-existent problem. I couldn't see a single benefit of using such a heavy approach. I quickly dismissed the article and continued to use Git the way I always did (I'll describe that way later in the article). Now, after having some hands-on experience with GitFlow, and based on my observations of others using (or, should I say more precisely, trying to use) it, that initial, intuitive dislike has grown into a well-founded, experienced distaste. In this article I want to explain precisely the reasons for that distaste, and present an alternative way of branching which is superior, at least in my opinion, to GitFlow in every way." And a summary of an alternative proposed there: http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow http://endoflineblog.com/oneflow-a-git-branching-model-and-w... "As the name suggests, OneFlow's basic premise is to have one eternal branch in your repository. This brings a number of advantages (see below) without losing any expressivity of the branching model - the more advanced use cases are made possible through the usage of Git tags. While the workflow advocates having one long-lived branch, that doesn't mean there aren't other branches involved when using it. On the contrary, the branching model encourages using a variety of support branches (see below for the details). What is important, though, is that they are meant to be short-lived, and their main purpose is to facilitate code sharing and act as a backup. The history is always based on the one infinite lifetime branch."

lsaferite 9y ago

So, being a fan of Fossil would make you a Hippster then, no? O_o I'll find my way out.

lsaferite 9y ago
So is it a lack of humor or just missing the joke that's getting the negative score?

krylon 9y ago

At work, I use fossil to manage my repository of scripts that I edit and use on different machines. (Strictly speaking, that could be done without an SCM, but I find it more convenient this way.) On Windows, that fact that fossil comes as a single statically-linked executable that works without any special installation procedure[0] is really nice. Also, I have to appreciate the builtin Wiki. I use it to keep a kind of diary of what I did and why, as well as gather helpful links I have come across over time. [0] Other than putting the executable somewhere on your %PATH%, of course.