Live data from Hacker News

Microsoft Office migration from Source Depot to Git

danielsada.tech

171–180 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#171
post #153
post #103

Earlier quoted context omitted.

Alternatively, communications fatigue. How many emails does the average employee get with nonsense that doesn't apply to them? Oh cool, we have a new VP. Oh cool, that department had a charity drive. Oh cool, system I've never heard of is getting replaced by a new one, favourite of this guy I've never heard of. Add in the various spam (be it attacks or just random vendors trying to sell something). At some point, peo…

Everybody gets important emails, and it's literally part of their job to filter the wheat from the chaff. One of my benchmarks for someone's competency is their ability to manage information. With a combination of email filters and mental discipline, even the most busy inbox can be manageable. But this is an acquired skill, akin to not getting lost in social media, and some people are far better at it than others.

If the same internal sender sends both irrelevant and important messages, it'll be pretty hard or impossible to filter.

My #1 method of keeping my inbox clean, is unsubscribing from newsletters.

Re: Microsoft Office migration from Source Depot to Git

#172
post #125
post #121

Earlier quoted context omitted.

Which is exactly how CVS (and its predecessors RCS and SCCS) worked. They were file based revision control, not repository based. SVN added folders like trunk/branches/tags that overlaid the file based versioning by basically creating copies of the files under each folder. Which is why branch creation/merging was such a complicated process, because if any of the files didn't merge, you had a half merged branch source…

CVS was called the “concurrent version system” because it did not lock files on checkout. Nor did svn. Perforce does.

Perforce does not lock files on checkout unless you have the file specifically configured to enforce exclusive locking in the file's metadata or depot typemap.

Re: Microsoft Office migration from Source Depot to Git

#173
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 cannot imagine many jobs use Discord over Slack/Teams unless they’re gaming related. This was not a gaming related job.

Re: Microsoft Office migration from Source Depot to Git

#174
post #139

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.

I used VSS for a few years back in the late 90's and early 2000's. It was better than nothing - barely - but it was very slow, very network intensive (think MS Access rather than SQL), it had very poor merge primitives (when you checked out a file, nobody else could change it), and yes, it was exceedingly prone to corruption. A couple times we just had to throw away history and start over.

Re: Microsoft Office migration from Source Depot to Git

#175
post #151

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 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 modernize legacy processes.

Re: Microsoft Office migration from Source Depot to Git

#177
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.

We use BitBucket where I work. Due to certain export regulations it's simpler for us to keep as many services as possible on-prem if they're going to contain any of our intellectual property, so BitBucket Server it is. There are other options of course, but all of the cloud solutions were off the table.

Re: Microsoft Office migration from Source Depot to Git

#178

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.

Can you not achieve the log history on a subtree with `git log my/subfolder/`? Tools like TortoiseGit let you right click on a folder and view the log of changes to it.

Yes it can, but the point is that in a git repo you store the entire history locally, so whenever you clone a repo, you clone its history on at least one branch.

So when you have a repo that's hundreds of GB in size, the entire history can be massive.

Re: Microsoft Office migration from Source Depot to Git

#179
post #139

Earlier quoted context omitted.

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.

I used VSS for a few years back in the late 90's and early 2000's. It was better than nothing - barely - but it was very slow, very network intensive (think MS Access rather than SQL), it had very poor merge primitives (when you checked out a file, nobody else could change it), and yes, it was exceedingly prone to corruption. A couple times we just had to throw away history and start over.

SourceSafe had a great visual merge tool. You could enable multiple checkouts. VSS had tons of real issues but not enabling multiple checkouts was a pain that companies inflicted on themselves. I still miss SourceSafe's merge tool sometimes.

Re: Microsoft Office migration from Source Depot to Git

#180
post #153

Earlier quoted context omitted.

Everybody gets important emails, and it's literally part of their job to filter the wheat from the chaff. One of my benchmarks for someone's competency is their ability to manage information. With a combination of email filters and mental discipline, even the most busy inbox can be manageable. But this is an acquired skill, akin to not getting lost in social media, and some people are far better at it than others.

If the same internal sender sends both irrelevant and important messages, it'll be pretty hard or impossible to filter. My #1 method of keeping my inbox clean, is unsubscribing from newsletters.

Our HR lady took personal offence when I asked to be unsubscribed from the emails about “deals” that employees have access to from corporate partners. :(
Post reply on HN