13 ms·

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s

by l0b0 7y ago

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the current contenders. Git made it possible to run VCS without a separate server program and sped up VCS operations massively. Both of those were huge. Looking at the Fossil home page[1] it does have some features I personally have wanted in VCSes, such as integrated "bug tracking, wiki, forum, and technotes," but the devil is very much in the details of how that actually works (How easy is it to write your own custom frontend or add business-critical bug tracking fields, for example?), and it's not like we don't already have good bug trackers, wikis etc. Just as a tangent, some issues (but not necessarily major or fundamental, depending on who you ask) with Git as it works right now: - Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism. - Git Annex is not yet built in. - The command line is complex, including many niche subcommands and tons of rarely used options. - The command line is inconsistent, such as `git rm` vs `git branch --delete` vs `git remote remove`. - It is based on a less than ideal theoretical model of patches[2]. IMO this is the most exciting development in VCSes since Git. [1] https://fossil-scm.org/ https://fossil-scm.org/ [2] https://pijul.org/model/ https://pijul.org/model/

rhabarba 7y ago
> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.
- wtetzner 7y ago
  How so?
  - rhabarba 7y ago
    Less overhead, a better UI.
    - peatmoss 7y ago
      Better support for large and binary artifacts
    - c-cube 7y ago
      horrendously slow `svn log`, locking files, bad branching… I only used it when I was a student but I don't miss svn at all.
- kstrauser 7y ago
  Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge from my brain. There's literally nothing about SVN that I prefer to Git, other than its UI was a little more pleasant.
  - codazoda 7y ago
    I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.
    - kstrauser 7y ago
      Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.
      - TwoHeadedBeast 7y ago
        Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.
    - duskwuff 7y ago
      Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.
- kempbellt 7y ago
  > Which is a better choice than Git for most projects, to be honest. That's pretty subjective. Most engineers I interact with personally know how to use Git but not SVN. I'd argue the opposite is true base on my subjective experience. Really depends on where/how you're using versioning, team familiarity, etc.
  - hinkley 7y ago
    It took me maybe eight months before I was willing to perform open heart surgery on a subversion repo. Two years to dare to try the same thing with git, and I was much more anxious about the whole thing. At the three year mark I have the same ambivalence about things working out that I did in less than a quarter of the time with the previous system. That’s a little too much to explain away with variability.
- lmm 7y ago
  Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).
  - bhaak 7y ago
    If all you had before was CVS then SVN wasn't a pain. Atomic commits and file renames.
    - lmm 7y ago
      SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.
      - bhaak 7y ago
        Sure but you could say the same about Git. With time, the standard requirements rise and we get more demanding. How about a VCS that not only diffs line by line but saves the diffs as editing delta? Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change? Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.
glandium 7y ago
- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism. https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt https://github.com/git/git/blob/master/Documentation/technic...
- l0b0 7y ago
  Thanks; admittedly the last time I looked into this was a few years ago. Glad to see it gaining traction!
hinkley 7y ago
I’ve been wondering if we need a slightly more general tool for tracking changes, that happens to have a VCS commandline as a first class client of that system. The problem is how to do bindings in many languages, or share one binding with some sort of IPC/RPC protocol. I have some collaboration tools I’d like to write but creating my own edit histories and conflict resolution is daunting.
bhaak 7y ago
I've seen nobody complain about the commit messages. Commit messages are not versioned. I can't go back and change the commit message to fix a typo or add something that was missed without changing the history. This always bothered me somewhat but now that I have non native and native people on the team that can't spell, I feel the pain everyday.
- philbarr 7y ago
  But you can go back and change a commit message with ammend? Or are you wanting to change other people's? https://www.atlassian.com/git/tutorials/rewriting-history#git-commit--amend https://www.atlassian.com/git/tutorials/rewriting-history#gi...
  - bhaak 7y ago
    Look at the URL: "rewriting-history" Ammending changes the hash of the commit. That doesn't matter if you haven't pushed it yet but if you have, you can't push the change upstream without force-pushing. And if I want to change a commit message further back in history (regardless of my own or of somebody else), it would branch off at that point from the upstream git history. What I want is that you could put multiple comments onto the same commit with different timestamps. Like git versions files, it should also allow to version commit messages.
    - chucky 7y ago
      You can accomplish something like this by using git-notes (https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes). You'd have to have your own tooling to read/write these in a convenient way of course.
      - bhaak 7y ago
        Yes but they are just a patch over the missing functionality. The key point is "your own tooling". Git has a great tool universe but unfortunately you immediately lose many tools if you go beyond what the core offers.

by l0b0 7y ago

rhabarba 7y ago

> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.

wtetzner 7y ago
How so?
- rhabarba 7y ago
  Less overhead, a better UI.
  - peatmoss 7y ago
    Better support for large and binary artifacts
  - c-cube 7y ago
    horrendously slow `svn log`, locking files, bad branching… I only used it when I was a student but I don't miss svn at all.
kstrauser 7y ago
Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge from my brain. There's literally nothing about SVN that I prefer to Git, other than its UI was a little more pleasant.
- codazoda 7y ago
  I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.
  - kstrauser 7y ago
    Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.
    - TwoHeadedBeast 7y ago
      Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.
  - duskwuff 7y ago
    Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.
kempbellt 7y ago
> Which is a better choice than Git for most projects, to be honest. That's pretty subjective. Most engineers I interact with personally know how to use Git but not SVN. I'd argue the opposite is true base on my subjective experience. Really depends on where/how you're using versioning, team familiarity, etc.
- hinkley 7y ago
  It took me maybe eight months before I was willing to perform open heart surgery on a subversion repo. Two years to dare to try the same thing with git, and I was much more anxious about the whole thing. At the three year mark I have the same ambivalence about things working out that I did in less than a quarter of the time with the previous system. That’s a little too much to explain away with variability.
lmm 7y ago
Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).
- bhaak 7y ago
  If all you had before was CVS then SVN wasn't a pain. Atomic commits and file renames.
  - lmm 7y ago
    SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.
    - bhaak 7y ago
      Sure but you could say the same about Git. With time, the standard requirements rise and we get more demanding. How about a VCS that not only diffs line by line but saves the diffs as editing delta? Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change? Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.

glandium 7y ago

- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism. https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt https://github.com/git/git/blob/master/Documentation/technic...

l0b0 7y ago
Thanks; admittedly the last time I looked into this was a few years ago. Glad to see it gaining traction!

hinkley 7y ago

I’ve been wondering if we need a slightly more general tool for tracking changes, that happens to have a VCS commandline as a first class client of that system. The problem is how to do bindings in many languages, or share one binding with some sort of IPC/RPC protocol. I have some collaboration tools I’d like to write but creating my own edit histories and conflict resolution is daunting.

bhaak 7y ago

I've seen nobody complain about the commit messages. Commit messages are not versioned. I can't go back and change the commit message to fix a typo or add something that was missed without changing the history. This always bothered me somewhat but now that I have non native and native people on the team that can't spell, I feel the pain everyday.

philbarr 7y ago
But you can go back and change a commit message with ammend? Or are you wanting to change other people's? https://www.atlassian.com/git/tutorials/rewriting-history#git-commit--amend https://www.atlassian.com/git/tutorials/rewriting-history#gi...
- bhaak 7y ago
  Look at the URL: "rewriting-history" Ammending changes the hash of the commit. That doesn't matter if you haven't pushed it yet but if you have, you can't push the change upstream without force-pushing. And if I want to change a commit message further back in history (regardless of my own or of somebody else), it would branch off at that point from the upstream git history. What I want is that you could put multiple comments onto the same commit with different timestamps. Like git versions files, it should also allow to version commit messages.
  - chucky 7y ago
    You can accomplish something like this by using git-notes (https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes). You'd have to have your own tooling to read/write these in a convenient way of course.
    - bhaak 7y ago
      Yes but they are just a patch over the missing functionality. The key point is "your own tooling". Git has a great tool universe but unfortunately you immediately lose many tools if you go beyond what the core offers.