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

281–290 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#281

Post by _whiteCaps_ »

tamlin wrote: post #139
0points wrote: post #130

Having used vss in the 90s myself, it surprised me it wasn't even mentioned. VSS (Visual SourceSafe) being Microsoft's own source versioning protocol, unlike Source Depot which was licensed from Perforce.

Yes, I used VSS as a solo developer in the 90s. It was a revelation at the time. I met other VCS systems at grad school (RCS, CVS). I started a job at MSFT in 2004 and I recall someone explaining that VSS was unsafe and prone to corruption. No idea if that was true, or just lore, but it wasn't an option for work anyway.

My memory is fuzzy on this but I remember VSS trusting the client for its timestamps and everything getting corrupted when someone's clock was out of sync. Which happened regularly because NTP didn't work very well on Windows back in the early 2000s.

Re: Microsoft Office migration from Source Depot to Git

#282

Post by DanielHB »

throwaway2037 wrote: post #268
DanielHB wrote: post #154

Earlier quoted context omitted.

I almost cried of happiness when we moved to git from SVN on my first job after being there for 6 months They might not be upset on the first few weeks but after a month or so they will be familiar with the pain.

> cried of happiness when we moved to git from SVN You bring back some real memories with this phrase. I recall moving from RCS and CVS and thinking: "Oh, this is a real improvement." (Forgive me; I was young.) Then, I moved from CVS to SVN and thought: "This is revolutionary. I can rename and merge." (Again, please withhold throwing your tomatoes until the end of the story!) Later, projects grew large enough, that S…

I never used CVS but I remember our internal joke about SVN is that SVN is like hotel California, you can branch but you can never leave [by merging the branch]

Re: Microsoft Office migration from Source Depot to Git

#283

Post by hypercube33 »

EvanAnderson wrote: post #246
chiph wrote: post #237

Earlier quoted context omitted.

VSS was picked up via the acquisition of One Tree Software in Raleigh. Their product was SourceSafe, and the "Visual" part was added when it was bundled with their other developer tools (Visual C, Visual Basic, etc). Prior to that Microsoft sold a version control product called "Microsoft Delta" which was expensive and awful and wasn't supported on NT. One of the people who joined Microsoft via the acquisition was Br…

> ...I seem to recall a big source of corruption was it's use of network file locking over SMB... Shared database files (of any kind) over SMB... shudder Those were such bad days.

As much as I wish for it, smb shares and access databases live on with the same awful problems they've always had with locking and concurrent users.

Re: Microsoft Office migration from Source Depot to Git

#284

Post by eliaspro »

tom_ wrote: post #252
nyarlathotep_ wrote: post #243

Earlier quoted context omitted.

Interesting. Seems antithetical to the 'git centered' view of being for source code only (mostly) I think I read somewhere that game dev teams would also check in the actual compiler binary and things of that nature into version control. Usually it's considered "bad practice" when you see, like, and entire sysroot of shared libs in a git repository. I don't even have any feeling one way or another. Even today "vendor…

It's only considered a bad idea because git handles it poorly. You're already putting all your code in version control - why would you not include the compiler binaries and system libraries too? Now everybody that gets the code has the right compiler to build it with as well! The better organised projects I've worked on have done this, and included all relevant SDKs too, so you can just install roughly the right vers…

I would say it's considered a bad idea, since git comes from an OpenSource world and its implied understanding, where you don't depend on a specific binary release to reproduce your results, but your results can always be reproduced purely from source - binaries are just considered a product of "the plaintext truth recorded in your repository".

Sure, there are nuances to it as the need for ReproducibleBuilds [1] project demonstrated or people proving this concept of "bootstrapped reproducibility" to the extremes like Guix' full-source bootstrap [2], but I believe the fundamental understanding is the same.

[1] https://reproducible-builds.org/

[2] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

Re: Microsoft Office migration from Source Depot to Git

#285

Post by tom_ »

nyarlathotep_ wrote: post #273
tom_ wrote: post #252

Earlier quoted context omitted.

It's only considered a bad idea because git handles it poorly. You're already putting all your code in version control - why would you not include the compiler binaries and system libraries too? Now everybody that gets the code has the right compiler to build it with as well! The better organised projects I've worked on have done this, and included all relevant SDKs too, so you can just install roughly the right vers…

> It's only considered a bad idea because git handles it poorly. You're already putting all your code in version control - why would you not include the compiler binaries and system libraries too? Now everybody that gets the code has the right compiler to build it with as well! No arguments here, it makes perfect sense to me as a practice. It's shortsighted to consider only "libraries" (as source, typically) to be "d…

Yes, this was a video game, targeting games consoles - so the executable statically links with pretty much everything, including stuff that would count as part of the OS on a PC. And then, if you can make sure everybody builds with the same libraries then you can be sure that everybody is running the same code. (I imagine this approach is also used for embedded development sometimes, another case where the build artefacts cover a much larger percentage of what gets run on the target than is the case with a PC.)

I will admit that even though I think it might be worth doing (and not doing it because your version control system doesn't make it easy is the worst reason for not doing it!), I'm not sure I'd consider it absolutely mandatory, certainly not for video games anyway. Most projects I've worked on haven't done this, and it's been fine, especially if you have a CI system doing the builds - and now the individual developers' systems just have to be roughly right. But it is nice to have, if you've got the right combination of personpower and institutional will to actually do it. It eliminates a whole category of possible issues straight away.

(I'd like to think that for safety critical stuff like medical or automotive this sort of approach, but done even more carefully, would be par for the course...!)

Re: Microsoft Office migration from Source Depot to Git

#286

Post by nyarlathotep_ »

tom_ wrote: post #285
nyarlathotep_ wrote: post #273

Earlier quoted context omitted.

> It's only considered a bad idea because git handles it poorly. You're already putting all your code in version control - why would you not include the compiler binaries and system libraries too? Now everybody that gets the code has the right compiler to build it with as well! No arguments here, it makes perfect sense to me as a practice. It's shortsighted to consider only "libraries" (as source, typically) to be "d…

Yes, this was a video game, targeting games consoles - so the executable statically links with pretty much everything, including stuff that would count as part of the OS on a PC. And then, if you can make sure everybody builds with the same libraries then you can be sure that everybody is running the same code. (I imagine this approach is also used for embedded development sometimes, another case where the build arte…

This is really cool, thanks for the info. I've always wondered about how this was done, especially for games.

> so the executable statically links with pretty much everything, including stuff that would count as part of the OS on a PC.

So this is something like whatever libc implementation was used? What era was this? "modern" ish consoles (ps4/XBox-whatever-from-the-last-decade)?

Re: Microsoft Office migration from Source Depot to Git

#287

Post by Marsymars »

kccqzy wrote: post #217
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…

Yeah but as a new hire, one doesn't yet know whether there is a good explanation for using a non-git tool. It takes time to figure that out. A legacy tool might be bad, or it might be very good but just unpopular. A company that devotes political will to modernize for the sake of modernizing is the kind of craziness we get in the JS ecosystem.

I mean if I'm a potential new hire, I'm just going to ask why they're not using Git, and give them the opportunity to give me a good explanation before I start there.

I'm with you on the JS ecosystem - I work on crufty .NET desktop apps - but you couldn't pay me to work on my crufty .NET apps using SVN.

Re: Microsoft Office migration from Source Depot to Git

#288

Post by dshacker »

jeffbee wrote: post #241

One thing I find annoying about these Perforce hate stories: yes it's awkward to branch in Perforce. It is also the case that there is no need to ever create a branch for feature development when you use Perforce. It's like complaining that it is hard to grate cheese with a trumpet. That just isn't applicable.

I mean yeah, in theory. I just found it really hard to work on multiple changes at a time vs git branches. Back in SD i used to have 2 or 3 machines + multiple VMs to be able to work on multiple things at a time. So I wouldn't say no need. In git I can do work, submit, switch, do work submit switch.

Re: Microsoft Office migration from Source Depot to Git

#289

Post by filoleg »

kccqzy wrote: post #277
filoleg wrote: post #230

Earlier quoted context omitted.

> 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,…

You missed the point. The point is, a new hire being asked to use a new version control software likely doesn't know whether the tool is more like hg or more like source depot. It takes times to figure out that. So they need to reserve judgement.

Not what I got out of that comment, but I fully agree with your take on new hires not being able to tell whether an unfamiliar version control piece of software is good or bad until they get at least somewhat familiar with it.

Re: Microsoft Office migration from Source Depot to Git

#290

Post by throwaway2037 »

tom_ wrote: post #270
throwaway2037 wrote: post #267

Earlier quoted context omitted.

> git style of shit I don't understand this phrase. Can you explain more?

It's a fairly typical Unix tool, but: worse! It's got a rather cryptic and unhelpful command line UI that's often fiddly to use, rather requires you to understand its internals in order to work with it, and has lots of perplexing failure modes. There are GUIs for it, which do help, but people moan at you if you use them, and/because they're often opinionated and oriented towards some specific workflow or other. And t…

In 2025, source code version control is incredibly complex. Hell, it was already complex 15 years ago, but the tools were probably worse! Have you ever seen the full manual for GCC/Clang? It is nuts. FFmpeg is legendary hard to use from the command line (no hate on Fabrice Bellard -- you still the man). Same for ImageMagick. I don't fault Git for it. If you want fine-grained control over every single possible action... well, you will wind up with a command line tool with an insane number of options.
Post reply on HN