Select from TFVC

More TFS Azure DevOps schema exploration. This time, source control. Specifically, the classic TFS source control, also known as TFVC. No Git this time, that is a discussion for another day.

So I have an innocent desire to run a report off the content of some files in source control. The question is, how are they stored? There are four tables of interest:

Can your ALM do that?

Support for runtime crash reporting and analysis should be a part of the Application Lifecycle Management (ALM).

Now, my exposure to the ALM landscape out there is limited. TFS/AzDevOps - I know it inside and out. Github (including the corporate edition) - moderate experience. GoCD, TeamCity, Jenkins - I have an idea what do they do.

Literacy is overrated

Imagine a table on a report with a boolean, yes/no column that indicates if the user presented a cookie during their web session. What would be a good column header for it?

Why, this text string, naturally:

🍪

Those are sixty four

Answering to this StackOverflow question, here's a list of Android device models that were seen supporting 64 bit code. No guarantee, though. The OS selection is up to the carrier; it could be the case that your carrier sells the same model with a 32-bit OS.

Internal extensions in TFS

Some of the TFS Azure DevOps functionality that comes out of the box is internally organized the same way third party extensions are. You can even see their manifests:

use Tfs_Configuration;
select p.DisplayName, p.PublisherName, e.ExtensionName,
    e.DisplayName, e.ShortDescription, cast(Content as varchar(max)) as Content
    from Gallery.tbl_Asset a
        inner join Gallery.tbl_Extension e on a.ReferenceID=e.ExtensionId
        inner join Gallery.tbl_Publisher p on e.PublisherId = p.PublisherId
        inner join tbl_FileReference r on a.FileId = r.FileId
        inner join tbl_Content c on r.ResourceId = c.ResourceId
    where AssetType = 'Microsoft.VisualStudio.Services.Manifest'
    order by e.ExtensionName, a.Version desc

I can see multiple versions of the same extension there, my TFS instance went through several version upgrades; on a freshly installed copy there would probably be only one.

Let me know, TFS

Today's obscure corner of the TFS REST API to explore would be - notifications. Some time ago, I've noticed that SOAP is no longer an option on the collection-level Notifications screen, but it's supported internally. If it's supported internally, then it must be supported by the API. Indeed it is, there's a REST API endpoint for subscription creation, and one of the parameters is called "channel", and it's supposed to be an instance of ISubscriptionChannel. That's where the docs go blank, except mentioning that it has a type property.

"Now" means last week

What the world needs is a dynamic database record/replay tool.

Okay, maybe not the world. But for me and for my software shop, that would address a need.

Migrating relational client-server databases from one version of the server software to another is a fact of life. So are breaking changes between versions.

So here's the idea: we take a snapshot of the production database, then record everything that's happening in it for, say, a month. Then we restore the snapshot on another database server, one with version N+1, and replay the recorded activity log against it. If the final state of the database matches the final state in production, then we know, with a good degree of assurance, that the system won't be broken by the version upgrade.

Nice vision. But there's a major monkey wrench in it - nondeterministic functions. If our goal is a database that's identical to the source, field for field, every input must exactly match, even the things that we don't usually consider input - the current time, the generated GUIDs, the numeric session IDs. That's why this vision is unlikely to come true without major support from the database vendor.

OAuth scopes in TFS 2019

Now that I have a TFS Azure DevOps 2019 box, let's dump the scopes from that one, too.

The same caveat applies: some of those might be cloud only.

TFS 2019 and commitment issues

My JavaScript TFS extensions broke in TFS Azure DevOps 2019. All my complaints about TFS API surface being underdocumented came to their logical conclusion: no docs means no API commitment, no commitment means the team behind the API gets to make breaking changes with no guilt.

Let me count the ways things broke: