
Ask HN: Is anyone using anything besides Git for version control? - mevile
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&#x27;s nothing else?
======
pwg
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
Are you using it?

~~~
pwg
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.

------
ssivark
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
Is anyone using it on the daily? How does it diverge from git?

------
scanny
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....](https://tortoisehg.readthedocs.io/en/latest/_images/pbranch.png)

------
core-questions
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
Where and what do you work on that uses such a terrible system?

------
jstewartmobile
Mercurial. Same idea, better interface.

~~~
mmmeff
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.

~~~
Lowkeyloki
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.

~~~
praneshp
> 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
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.

------
bifrost
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
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.

------
Someone1234
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
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.

~~~
SOLAR_FIELDS
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.

~~~
sempron64
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.

------
ndoshaben
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.

------
sleepybrett
I've seen perforce here and there still.

~~~
josephg
Perforce is used all over the place in the games industry. Not sure how many
game developers frequent HN though.

~~~
mdouglass
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.

------
awiesenhofer
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.

------
stephenr
The vast majority of my projects are in mercurial repos. I use git for some
forks and on some client projects.

------
kpU8efre7r
Clearcase.

It is horrendous but I am stuck with it.

------
emit_time
Sourcegear vault... it sucks. Branching is really expensive, it’s mainly GUI
based...

~~~
cgrealy
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
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 >.<

------
cauterize
For old and painful see Accurev. And yes, I believe it is still used.

------
adelarsq
Using subversion on all projects from my company

------
jhwhite
Subversion for some stuff. GitHub for others.

------
droptablemain
Mercurial on some client projects.

