6 ms·

CVS used to be the standard before Git. Arguably CVS as the standard was not better than no standard if no standard let you use decentralized version control.

by nequo 4y ago

CVS used to be the standard before Git. Arguably CVS as the standard was not better than no standard if no standard let you use decentralized version control. But Git is pretty good, so it will take something vastly better to replace it.

deleted 4y ago
[deleted]
jiggywiggy 4y ago
Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantly less painful way at some point.
- throwawayadvsec 4y ago
  well merging two wildly different of files is going to be complicated using any tool, git is not the issue there, there isn't a million ways to handle this
  - dmoy 4y ago
    Right it's a use type thing. If everyone develops from master branch and makes small incremental changes, no problem even if it's git. If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either. If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
  - nirimda 4y ago
    There's three ways. One is the git way, which is to let people do whatever and then ask them to handle it afterwards. The next best is used by some other annoying system I used early in my career, which is to require people to check out a file before they can get write permission on it, and only allow one person to have write permission at once, so that there's no real risk of merges. And the worst of all is to just let whoever comes later overwrite whatever was there before.
- jdmichal 4y ago
  I've used many different version control systems. Git is, by far, the best at merging and avoiding conflicts to start with. I believe it's because it can often work from the basis of a common ancestor commit, so it's able to perform three-way merges instead of two-way merges.
  - HWR_14 3y ago
    Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
    - jdmichal 3y ago
      Three-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge. I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
      - HWR_14 3y ago
        Ah, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial). A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it. But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
- prettyStandard 4y ago
  I love rebasing. As for dealing with merge conflicts, it's called - keep up to date with the branch your tracking - merge frequently - get on a call when you do have merge conflicts - avoid having multiple people working in the same files simultaneously if possible The problem with merge conflicts is you have two people changing the same lines of code at the same time. So I would imagine if you wanted to improve the situation you would need an AI powered version control system that understood the intent of the previous developers. But that's not going to fix bad habits.
  - yjftsjthsd-h 4y ago
    > As for dealing with merge conflicts, it's called That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
- jcranmer 4y ago
  Mercurial's phases and changeset evolution make specifically rebasing far less painful. git rebase -i is downright antediluvian in comparison.
- prepend 4y ago
  Merges are hard and I’ve never seen a system that removes the difficulty. I actually think git is the best because it’s easier to branch and update than many others (a pull takes a second to refresh vs quite a while for large repos with svn). I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
- adastra22 4y ago
  The solution is darcs’ patch-theory model of development, currently being pushed forward by pijul.
  - gavinhoward 4y ago
    I am making a VCS to compete against Git and Pijul. The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt. But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
    - adastra22 3y ago
      Please share when it is ready!
      - gavinhoward 3y ago
        Absolutely! I am planning to make a "Show HN" my official announcement, but only after it is self-hosting and has enough features to replace my Gitea instance.
gspencley 4y ago
CVS, subversion and mercurial are all VCS tools that I remember using throughout the years. Didn't Microsoft even have its own for a while? I swear I remember Visual C++ integration features back in the 90s / early 00s but I can't remember what it was called.
- HappyJoy 4y ago
  Team Foundation Version Control Edit: And Visual Source Safe
- Sander_Marechal 4y ago
  Yes, MS Visual Sourcesafe (VSS). It was... not very good
  - grimjack00 4y ago
    It was, however, a step up from the shared network drive with a bunch of zip files.
    - politician 4y ago
      Debatable. You would come into work in the morning and find that VSS had been corrupted and needed to be restored to an earlier backup. This was a common occurrence.
      - prepend 4y ago
        That the lovely common occurrence of someone checking out 1000 files and going on vacation. I preferred just a normal folder, rsync (or some nt utils equivalent) and backups.
  - wheelie_boy 4y ago
    they also had an internal source control system that they never released, which was a fork of perforce that they had purchased the rights to use and modify. Not sure if that's still in use in any projects.
lolinder 4y ago
My understanding is that before git a substantial portion of the industry used the "one big shared drive and shouting across the room to lock files" version control system. There was also SVN that was pretty popular pre-git. I don't believe any version control system achieved as deep industry penetration as git has.
- andreabergia 4y ago
  In my experience, SVN was _everywhere_ 10 years ago or so.
  - pcthrowaway 4y ago
    I used SVN once for my capstone project 11 years ago, graduated that same year, and literally haven't encountered it a single time in my career since then. It definitely wasn't everywhere 10 years ago (but github was). Do you mean 15-20? Regardless, having completed a CS degree during the period SVN was supposedly everywhere and only encountered it once because someone in my capstone team knew how to use it, I'm inclined to think it didn't permeate everything the way git does now. If I could complete a bachelors in CS without encountering it in any of my courses, I think it's safe to say git is much more ingrained in the field now (pretty much every syllabus I come across online for CS courses from the last 5 years has had some github links)
  - Klonoar 3y ago
    SVNs heyday is closer to 15 years ago at this point.
- liveoneggs 4y ago
  subversion was just as dominant as git is now. Not using version control at all is probably just as common as it was previously.
  - morelisp 4y ago
    SVN took over the hobbyist area rapidly due to its workflow/UI similarity to CVS, but P4 held fast professionally until at least 2015, as well as Source Safe if you were an MS shop. (And conservative places never switched off CVS at all.)
deleted 4y ago
[deleted]
JohnFen 4y ago
> But Git is pretty good, so it will take something vastly better to replace it. Git is fine, but honestly, my favorite of the several I've used over the years is still svn.
forrestthewoods 4y ago
> But Git is pretty good, so it will take something vastly better to replace it. Correction: Git is super mediocre, but sufficiently wide spread it will take something vastly better to replace it. Don’t confuse inertia with goodness.
- MetaWhirledPeas 4y ago
  Git is solving a very complicated problem with a command line tool. Don't confuse a complicated problem with a mediocre application.
  - forrestthewoods 3y ago
    Git is a mediocre CLI, imho, ymmv. GitHub I don’t have a strong opinion on.
    - nequo 3y ago
      But Git is not only the porcelain, it’s also the plumbing. Do you think that the plumbing is super mediocre too?
      - forrestthewoods 3y ago
        I don’t know what that analogy is supposed to mean. I don’t think analogies are necessary or appropriate here.
        nequo 3y ago
        This is the terminology that Git uses. Porcelain is the UI, whether it’s the basic CLI, Magit, Fugitive, or anything else. Plumbing is Git under the UI. Are you saying that the CLI is bad, or that Git’s underlying concepts and data model are bad?
        forrestthewoods 3y ago

by nequo 4y ago

deleted 4y ago

[deleted]

jiggywiggy 4y ago

Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantly less painful way at some point.

throwawayadvsec 4y ago
well merging two wildly different of files is going to be complicated using any tool, git is not the issue there, there isn't a million ways to handle this
- dmoy 4y ago
  Right it's a use type thing. If everyone develops from master branch and makes small incremental changes, no problem even if it's git. If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either. If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
- nirimda 4y ago
  There's three ways. One is the git way, which is to let people do whatever and then ask them to handle it afterwards. The next best is used by some other annoying system I used early in my career, which is to require people to check out a file before they can get write permission on it, and only allow one person to have write permission at once, so that there's no real risk of merges. And the worst of all is to just let whoever comes later overwrite whatever was there before.
jdmichal 4y ago
I've used many different version control systems. Git is, by far, the best at merging and avoiding conflicts to start with. I believe it's because it can often work from the basis of a common ancestor commit, so it's able to perform three-way merges instead of two-way merges.
- HWR_14 3y ago
  Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
  - jdmichal 3y ago
    Three-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge. I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
    - HWR_14 3y ago
      Ah, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial). A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it. But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
prettyStandard 4y ago
I love rebasing. As for dealing with merge conflicts, it's called - keep up to date with the branch your tracking - merge frequently - get on a call when you do have merge conflicts - avoid having multiple people working in the same files simultaneously if possible The problem with merge conflicts is you have two people changing the same lines of code at the same time. So I would imagine if you wanted to improve the situation you would need an AI powered version control system that understood the intent of the previous developers. But that's not going to fix bad habits.
- yjftsjthsd-h 4y ago
  > As for dealing with merge conflicts, it's called That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
jcranmer 4y ago
Mercurial's phases and changeset evolution make specifically rebasing far less painful. git rebase -i is downright antediluvian in comparison.
prepend 4y ago
Merges are hard and I’ve never seen a system that removes the difficulty. I actually think git is the best because it’s easier to branch and update than many others (a pull takes a second to refresh vs quite a while for large repos with svn). I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
adastra22 4y ago
The solution is darcs’ patch-theory model of development, currently being pushed forward by pijul.
- gavinhoward 4y ago
  I am making a VCS to compete against Git and Pijul. The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt. But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
  - adastra22 3y ago
    Please share when it is ready!
    - gavinhoward 3y ago
      Absolutely! I am planning to make a "Show HN" my official announcement, but only after it is self-hosting and has enough features to replace my Gitea instance.

gspencley 4y ago

CVS, subversion and mercurial are all VCS tools that I remember using throughout the years. Didn't Microsoft even have its own for a while? I swear I remember Visual C++ integration features back in the 90s / early 00s but I can't remember what it was called.

HappyJoy 4y ago
Team Foundation Version Control Edit: And Visual Source Safe
Sander_Marechal 4y ago
Yes, MS Visual Sourcesafe (VSS). It was... not very good
- grimjack00 4y ago
  It was, however, a step up from the shared network drive with a bunch of zip files.
  - politician 4y ago
    Debatable. You would come into work in the morning and find that VSS had been corrupted and needed to be restored to an earlier backup. This was a common occurrence.
    - prepend 4y ago
      That the lovely common occurrence of someone checking out 1000 files and going on vacation. I preferred just a normal folder, rsync (or some nt utils equivalent) and backups.
- wheelie_boy 4y ago
  they also had an internal source control system that they never released, which was a fork of perforce that they had purchased the rights to use and modify. Not sure if that's still in use in any projects.

lolinder 4y ago

My understanding is that before git a substantial portion of the industry used the "one big shared drive and shouting across the room to lock files" version control system. There was also SVN that was pretty popular pre-git. I don't believe any version control system achieved as deep industry penetration as git has.

andreabergia 4y ago
In my experience, SVN was _everywhere_ 10 years ago or so.
- pcthrowaway 4y ago
  I used SVN once for my capstone project 11 years ago, graduated that same year, and literally haven't encountered it a single time in my career since then. It definitely wasn't everywhere 10 years ago (but github was). Do you mean 15-20? Regardless, having completed a CS degree during the period SVN was supposedly everywhere and only encountered it once because someone in my capstone team knew how to use it, I'm inclined to think it didn't permeate everything the way git does now. If I could complete a bachelors in CS without encountering it in any of my courses, I think it's safe to say git is much more ingrained in the field now (pretty much every syllabus I come across online for CS courses from the last 5 years has had some github links)
- Klonoar 3y ago
  SVNs heyday is closer to 15 years ago at this point.
liveoneggs 4y ago
subversion was just as dominant as git is now. Not using version control at all is probably just as common as it was previously.
- morelisp 4y ago
  SVN took over the hobbyist area rapidly due to its workflow/UI similarity to CVS, but P4 held fast professionally until at least 2015, as well as Source Safe if you were an MS shop. (And conservative places never switched off CVS at all.)

deleted 4y ago

[deleted]

JohnFen 4y ago

> But Git is pretty good, so it will take something vastly better to replace it. Git is fine, but honestly, my favorite of the several I've used over the years is still svn.

forrestthewoods 4y ago

> But Git is pretty good, so it will take something vastly better to replace it. Correction: Git is super mediocre, but sufficiently wide spread it will take something vastly better to replace it. Don’t confuse inertia with goodness.

MetaWhirledPeas 4y ago
Git is solving a very complicated problem with a command line tool. Don't confuse a complicated problem with a mediocre application.
- forrestthewoods 3y ago
  Git is a mediocre CLI, imho, ymmv. GitHub I don’t have a strong opinion on.
  - nequo 3y ago
    But Git is not only the porcelain, it’s also the plumbing. Do you think that the plumbing is super mediocre too?
    - forrestthewoods 3y ago
      I don’t know what that analogy is supposed to mean. I don’t think analogies are necessary or appropriate here.
      - nequo 3y ago
        This is the terminology that Git uses. Porcelain is the UI, whether it’s the basic CLI, Magit, Fugitive, or anything else. Plumbing is Git under the UI. Are you saying that the CLI is bad, or that Git’s underlying concepts and data model are bad?
        forrestthewoods 3y ago