Y HN SearchHacker News Search

new|comments|top|jobs

loading thread…

13 ms·

Ask HN: Is anyone using anything besides Git for version control?

17 points by mevile 7y ago

Just wondering what else is out there in the world of version control. Anything new and exciting? New and exciting additions to older and familiar version control systems? Or is git just the thing and there's nothing else?

pwg 7y ago
One other is Fossil: https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
- Something1234 7y ago
  Are you using it?
  - pwg 7y ago
    Myself, no, but that has as much to do with the fact that I started using git long ago before either Fossil existed or before I learned of its existence. But to be fair, the OP's question did not ask "what are you using" but rather "what else is out there". Referencing Fossil is valid for a "what else is out there" query, even if one is not, at present, using Fossil. I have looked at it from time to time, and having a whole turnkey "github like" interface all in one program is a nice feature that has its appeal. But I have not had a need for all of that (yet) so I have not made much use of it beyond experimenting.
- Lowkeyloki 7y ago
  I want so much to like Fossil. But I feel like it's too closely tailored to Dwayne Hipp's workflow. I'm also not so hot on the jack of all trades approach of the built-in issue tracker, wiki, etc. It goes against my Unix philosophy sensibilities. But that's just my 2¢.
- zebproj 7y ago
  I am a casual user of Fossil. I tried it out for some of my smaller projects. I can't say I am at the point where I "get" it, but I'd definitely recommend at least trying it out, as it provides a contrasting perspective to source control (from git). The integrated Wiki and ticketing system can be very helpful. The built-in web interface is definitely convenient. Also, the codebase is written in very clean C code (it's written by the SQLite devs, so I expect no less from them). It is very easy to compile from source. Also, the documentation they have is quite nice. I definitely struggle with parts of Fossil. Fossil does not make it easy to revise commits (this is an intentional design). I one time made a commit on a badly time-skewed machine and it took me all day to look up how to correct that (but I found it in their documentation). I'm also still getting the hang of how branching works in Fossil. It is very hard to have a massive amount of contributors to code. Again, this is another intentional design choice. It's certainly not a VCS for all projects. But for certain kinds of projects, it really works well.
- LVB 7y ago
  I used it for personal projects for a while. The built in Wiki and history viewer were actually pretty useful, but I found the limitations on history mutations pretty annoying. My view is that especially for a local, personal project, I should be able to maintain things however I want. Alas, back to git.
core-questions 7y ago
Some of our teams use Darcs, which is older than Git but has many of the same advantages at a raw level. Unfortunately it's not very well supported by CI tools and there's no fancy web front end like Github / Bitbucket to use. I'm not a huge fan, but it looks like we're going to keep using it for the foreseeable future.
- Something1234 7y ago
  Where and what do you work on that uses such a terrible system?
sleepybrett 7y ago
I've seen perforce here and there still.
- josephg 7y ago
  Perforce is used all over the place in the games industry. Not sure how many game developers frequent HN though.
  - mdouglass 7y ago
    Second that. Only thing I’ve seen in the studios I’ve worked at for game clients. Here and there I see game servers moving into git if they aren’t sharing a codebase with the client.
- mj_olnir 7y ago
  I use Perforce at a financial trading firm.
- cauterize 7y ago
  We (big internet company) still use Perforce. It works quite well for a 20 year old company that never deleted anything.
bifrost 7y ago
cvs, subversion, rcs when I'm really doing something awful. I use git a decent amount because its what the project I'm working on is using.
- fetus8 7y ago
  A lot of the legacy projects at my company are still being hosted on an active Subversion server. Even some of our newer projects are still using it. It's alive and well here.
jstewartmobile 7y ago
Mercurial. Same idea, better interface.
- mmmeff 7y ago
  I started using Mercurial in college and then switched to git at my first job. I haven't seen Mercurial since. I still don't understand how Git won in the long run, it's CLI is so much worse than `hg`. My guess would be that Bitbucket added `git` support before Github added `hg` support.
  - omosubi 7y ago
    Why is the mercurial interface better than git? They're pretty similar in most cases besides the branching thing and a couple different commands
    - Lowkeyloki 7y ago
      Mercurial's interface makes more sense if you're migrating from a svn workflow, for example.
    - jstewartmobile 7y ago
      99% of the time, I can get away with: hg push/pull/up/commit/diff/status without additional flags. I can't say the same for git.
  - Lowkeyloki 7y ago
    Git made some design decisions that sacrifice usability for speed when you're dealing with a gigantic repository on the scale of the Linux kernel, which is what it was designed for. I believe that git won out over mercurial for the same reason that small start ups choose systems and processes that are the same as those used by big players like Google, Facebook, Amazon, etc. People should try to make design decisions and choose tools for the scale they're actually at. Not the scale they hope to be at some day.
    - 7y ago
Someone1234 7y ago
We're using Team Foundation Version Control via Azure DevOps. I do not recommend TFVC, DevOps is "fine" though. The biggest problem is that branching is expensive and slow. We have 7K files in master, so for each branch we're copying and downloading 7K files. It takes 10+ minutes to simply make and clone a branch. It isn't smart enough to re-use files it already has in the workspace. We're looking to move to Git which DevOps also supports. If for no other reasons less expensive branching and better code reviews ("pull requests" in Git lingo).
- sempron64 7y ago
  I had success porting our ancient TFS repository to git while preserving history with git-tfs https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-tfs If you have many years of history, it will take a long time to import, so you may want to try getting the history of a subdirectory first. The team, which was unfamiliar with git up until that point, was very happy with it. Unfortunately the Git integration in Visual Studio was/is pretty terrible -- it did not even support git stash until VS 2019 (which I'm not using yet). So try to have your teammates learn the command line workflow first. Those who used only the VS GUI had a lot of trouble. Also, doing git operations in the IDE sucks because it will constantly reload the project. This is true of TFVC as well, but you can avoid it with an external git client.
  - Someone1234 7y ago
    Thanks I'll check it out.
  - SOLAR_FIELDS 7y ago
    I am quite interested in who uses Git GUI’s vs the command line tool (and which tools they use if GUI). Command line is going to be more robust but given the difficulty in learning Git (I end up teaching people much more senior than me some of the tricks) I can imagine that more people use the GUI than I would initially think. I’ve found GUI’s only to be useful in one or two specific examples: complicated rebases and merge conflicts. In all other cases the CLI workflow seems faster.
ssivark 7y ago
Since you're looking for some excitement, do check out Pijul: https://pijul.org/ https://pijul.org/ EDIT: For questions about the motivation vis-a-vis git, refer https://pijul.org/faq/ https://pijul.org/faq/
- Lowkeyloki 7y ago
  Is anyone using it on the daily? How does it diverge from git?
- mevile 7y ago
  This is interesting, thank you, I will give it a try!
awiesenhofer 7y ago
For a quick config change or versioning that one shell script keeping a server running when it encounters that one weird error every full moon there is also still RCS readily avaiable almost everywhere. Saved us so many headaches over the years.
ndoshaben 7y ago
I work on embedded systems in the automotive industry and unfortunately most companies are still using old enterprise software for source control and task management. We are using PTC Integrity for the project that I am on, but another project in the company has been using git/bitbucket/jira, so I'm hoping that they we can adopt that at some point.
emit_time 7y ago
Sourcegear vault... it sucks. Branching is really expensive, it’s mainly GUI based...
- cgrealy 7y ago
  ugh, I feel your pain. Have had to use that in the past, it's basically one step up from SourceSafe. The first thing I did at the last company that used it was migrate to git. The good news is that (from memory) there is a tool that will migrate all the history to git.
  - emit_time 7y ago
    Yup, I evaluated the tool and got it working with our repo in a trial run, hopefully going to do some git testing in the near future... when I have time to write some scripts. What tool did you use? Also how did you migrate who did commits etc, I found and updated branch of the vault2git tool, but it didn’t have an explanation of how to use the xml for mapping branches and such... I’m honesty forgetting it’s been a few months since I looked at it... I’m hopefully though. Sorry for the rant >.<
adelarsq 7y ago
Using subversion on all projects from my company
droptablemain 7y ago
Mercurial on some client projects.
stephenr 7y ago
The vast majority of my projects are in mercurial repos. I use git for some forks and on some client projects.
cauterize 7y ago
For old and painful see Accurev. And yes, I believe it is still used.
jhwhite 7y ago
Subversion for some stuff. GitHub for others.
kpU8efre7r 7y ago
Clearcase. It is horrendous but I am stuck with it.
scanny 7y ago
Mercurial has been pretty good, especially with tortoiseHg and seeing the visual branches flowing along. We use this in a fairly large team with remote workers, and it works like a charm. Only the merge conflict interface could use work, but it integrates with visual studio code quite nicely. https://tortoisehg.readthedocs.io/en/latest/_images/pbranch.png https://tortoisehg.readthedocs.io/en/latest/_images/pbranch....

> People should try to make design decisions and choose tools for the scale they're actually at. Not the scale they hope to be at some day. Would you accept that there is at least some sort of movement of engineers from these large companies to startups? I would argue the choice is made on what people are used to and familiar with, as opposed to "let's signal what scale we want to be at in our choice of tools"

Lowkeyloki 7y ago
That hasn't been my experience in a decade in the industry. I've never worked at a company with a single person who has worked at any of the big silicon valley tech companies. But I've seen people choose technologies, tools, designs, and processes because that's what company X uses. None of the companies I've worked at have been even a tenth of the size of Google or Facebook. None of the companies has had one one hundredth of the amount of activity in their repositories that you'd find in the Linux kernel.

jstewartmobile 7y ago

Not sure if this is still the case, but Google & FB circa 2010 is still a metric shitload of code: https://news.ycombinator.com/item?id=10228399 https://news.ycombinator.com/item?id=10228399

muzani 7y ago

I hear Facebook uses Mercurial because Git doesn't have the scale they need.

duiker101 7y ago

I like HG better too. But i ended up using got more because pretty much everyone in the industry at works uses git and I need to make sure I develop the most useful skill. Not that's git is hard, but there's always to learn.

sempron64 7y ago

A significant portion (30-50%) of the team mostly use the Visual Studio integration and are happy, it's not too different from their previous workflow. The merge conflict experience is not too bad as you get the nice integrated conflict editor. The real issue managing committed but locally-modifiable config files. De-indexing is not a good option because once they're de-indexed there's no way to manually add them in Visual Studio, and I don't want to force everyone to open the CLI to run git add. Most of our developers continually stash these files. This means staging and committing is a painful process. I hate that I can't git commit -a as well... Those who write javascript and use Visual Studio Code mostly use the CLI now in the integrated terminal (they are very happy to not have to open up VS to commit). Deployment engineers who don't use Visual Studio often and some other teams who started using Git earlier prefer Atlassian Source Tree.