Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Office migration from Source Depot to Git

danielsada.tech

Post reply on HN
Print view View original

221–230 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#221

Post by kccqzy »

tough wrote: post #184
Marsymars wrote: post #175

Earlier quoted context omitted.

I feel like I’ve got an open mind towards processes and tools; the problem with a company using anything other than Git at this point is that unless they have a good explanation for it, it’s not going to be an indicator that the company compared the relative merits of VCS systems and chose something other than Git - it’s going to be an indicator that the company doesn’t have the bandwidth or political will to moderni…

maybe they're on bazel?

Well bazel is not a tool for version control.

Re: Microsoft Office migration from Source Depot to Git

#223

Post by inglor »

kccqzy wrote: post #151
noitpmeder wrote: post #150

Earlier quoted context omitted.

My firm still uses perforce and I can't say anyone likes it at this point. You can almost see the light leaves the eyes of new hires when you tell them we don't use git like the rest of the world.

I cannot believe that new hires would be upset by the choice of version control software. They joined a new company after so many hoops and it's on them for having an open mind towards processes and tools in the new company.

The problem is that you come to a prestigious place like Microsoft and end up using horrible outdated software.

Credit where credit is due at my time at Excel we did improve things a lot (migration from Script# to TypeScript, migration from SourceDepot to git, shorter dev loop and better tooling etc) and a large chunk of development time was spent on developer tooling/happiness.

But it does suck to have to go to one of the old places and use sourcedepot and `osubmit` the "make a change" tool and then go over 16 popups in the "happy path" to submit your patch for review (also done in a weird windows gui review tool)

Git was quite the improvement :D

Re: Microsoft Office migration from Source Depot to Git

#224

Post by kccqzy »

WorldMaker wrote: post #202
foooorsyth wrote: post #163

Earlier quoted context omitted.

git by itself is often unsuitable for XL codebases. Facebook, Google, and many other companies / projects had to augment git to make it suitable or go with a custom solution. AOSP with 50M LoC uses a manifest-based, depth=1 tool called repo to glue together a repository of repositories. If you’re thinking “why not just use git submodules?”, it’s because git submodules has a rough UX and would require so much wranglin…

It's interesting to point out that almost all of Microsoft's "augmentations" to git have been open source and many of them have made it into git upstream already and come "ready to configure" in git today ("conical" sparse checkouts, a lot of steady improvements to sparse checkouts, git commit-graph, subtle and not-so-subtle packfile improvements, reflog improvements, more). A lot of it is opt-in stuff because of bac…

Meta and Google both have been using mercurial and they have also been contributing back to upstream mercurial.

Re: Microsoft Office migration from Source Depot to Git

#226

Post by const_cast »

evilduck wrote: post #161
mattl wrote: post #159

Earlier quoted context omitted.

I worked with someone who was surprised the company didn’t use Bitbucket and Discord. They were unhappy about both.

Discord I get, at least from a community or network effect, but Bitbucket? I can’t figure out why anyone but a CTO looking to save a buck would prefer Bitbucket.

I actually quite like the interface of bitbucket. I think it's better, in a lot of ways, compared to gitlab and github.

What I hate about bitbucket is how stagnated it is.

Re: Microsoft Office migration from Source Depot to Git

#227

Post by dh2022 »

masklinn wrote: post #212
dh2022 wrote: post #209

Earlier quoted context omitted.

Hmm, I do not get it.... "The binaries are checked in the repo so that that the designer would not spend 5 hours recompiling" vs "the binaries come from a nuget site so that the designed would not spend 5 hours recompiling". In both cases the designer does not recompile, but in the second case there are no checked in binaries in the repo... I still think nuget / MAVEN would be more appropriate for this task...

Everything is in P4: you checkout the project to work on it, you have everything. You update, you have everything up to date. All the tools are there, so any part of the pipeline can rely on anything that's checked in. You need an older version, you just check that out and off you go. And you have a single repository to maintain. VCS + Nuget: half the things are in the VCS, you checkout the project and then you have…

I have no idea what environment / team you worked on but nuget is pretty much rock solid. There are no scripts running on a prayer that everything is fetched. Version sync is not a crapshot because nuget versions are updated during merges and with proper merge procedures (PR build + tests) nuget versions are always correct on the main branch.

One does not forget what nugets are used: VS projects do that bookkeeping for you. You update the VS project with the new nugets your task requires; and this bookkeeping will carry on when you merge your PR.

I have seen this model work with no issues in large codebases: VS solutions with upwards of 500,000 lines of code and 20-30 engineers.

Re: Microsoft Office migration from Source Depot to Git

#228

Post by swsieber »

jjmarr wrote: post #208
swsieber wrote: post #193

Earlier quoted context omitted.

I'm a bit surprised git doesn't offer a way to checkout only specific parts of the git tree to be honest. It seems like it'd be pretty easy to graft on with an intermediate service that understands object files, etc.

It's existed for a while. Partial clones and LFS. https://git-scm.com/docs/partial-clone

Thanks!

Re: Microsoft Office migration from Source Depot to Git

#229

Post by [deleted] »

int_19h wrote: post #198
sixothree wrote: post #166

Earlier quoted context omitted.

Doesn’t SVN let you check out and commit any folder or file at any depth of a project you choose? Maybe not the checkouts and commit, but that log history for a single subtree is something I miss from the SVN tooling.

You can indeed. The problem with this strategy is that now you need to maintain the list of directories that needs to be checked out to build each project. And unless this is automated somehow, the documentation will gradually diverge from reality.

[deleted]

Re: Microsoft Office migration from Source Depot to Git

#230

Post by filoleg »

kccqzy wrote: post #151
noitpmeder wrote: post #150

Earlier quoted context omitted.

My firm still uses perforce and I can't say anyone likes it at this point. You can almost see the light leaves the eyes of new hires when you tell them we don't use git like the rest of the world.

I cannot believe that new hires would be upset by the choice of version control software. They joined a new company after so many hoops and it's on them for having an open mind towards processes and tools in the new company.

> I cannot believe that new hires would be upset by the choice of version control software.

I can, if the version control software is just not up to standards.

I absolutely didn’t mind using mercurial/hg, even though I literally haven’t touched it until that point and knew nothing about it, because it is actually pretty good. I like it more than git now.

Git is a decent option that most people would be familiar with, cannot be upset about it either.

On another hand, Source Depot sucked badly, it felt like I had to fight against it the entire time. I wasn’t upset because it was unfamiliar to me. In fact, the more familiar I got with it, the more I disliked it.

Post reply on HN