Ask HN: Is anyone using anything besides Git for version control?
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?
46 comments
Since you're looking for some excitement, do check out Pijul: https://pijul.org/
EDIT: For questions about the motivation vis-a-vis git, refer https://pijul.org/faq/
EDIT: For questions about the motivation vis-a-vis git, refer https://pijul.org/faq/
Is anyone using it on the daily? How does it diverge from git?
This is interesting, thank you, I will give it a try!
Sourcegear vault... it sucks.
Branching is really expensive, it’s mainly GUI based...
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.
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.
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 >.<
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 >.<
One other is Fossil: https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
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.
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.
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.
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¢.
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¢.
Are you using it?
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.
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.
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.
I'm not a huge fan, but it looks like we're going to keep using it for the foreseeable future.
Where and what do you work on that uses such a terrible system?
I've seen perforce here and there still.
Perforce is used all over the place in the games industry. Not sure how many game developers frequent HN though.
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.
We (big internet company) still use Perforce. It works quite well for a 20 year old company that never deleted anything.
I use Perforce at a financial trading firm.
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.
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.
Mercurial. Same idea, better interface.
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.
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.
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.
> 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"
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"
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.
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
Why is the mercurial interface better than git? They're pretty similar in most cases besides the branching thing and a couple different commands
99% of the time, I can get away with:
hg push/pull/up/commit/diff/status
Mercurial's interface makes more sense if you're migrating from a svn workflow, for example.
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.
I hear Facebook uses Mercurial because Git doesn't have the scale they need.
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).
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).
I had success porting our ancient TFS repository to git while preserving history with 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.
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.
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.
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.
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.
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.
Thanks I'll check it out.
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.
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.
Using subversion on all projects from my company
Mercurial on some client projects.
The vast majority of my projects are in mercurial repos. I use git for some forks and on some client projects.
For old and painful see Accurev. And yes, I believe it is still used.
Subversion for some stuff. GitHub for others.
Clearcase.
It is horrendous but I am stuck with it.
It is horrendous but I am stuck with it.
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....
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....
