I started at a new company today and am setting up my new laptop. I thought I would spend a few minutes writing my standard list of software that I install by default, for my future self (and perhaps, others).
Must have software:
The change feed functionality in Azure Cosmos DB is a great feature with a wide variety of uses. The change feed subscribes to changes that occur in a collection and keeps its state in another collection, called the Lease Collection. Because the minimum RUs in a collection are 400 and a single lease hardly uses 50 of the RUs, we had decided to store additional meta data documents in the same lease collection, because we could not use the Continuation Token and Sequence Number data to determine where in the stream the subscriber was (for our own monitoring purposes). Don’t do this! The change feed library will regularly scan and pull all documents in this collection and use it to balance the subscribers and therefore the more documents are in this collection, the greater the RU requirements. Our RUs were bumping against 4,000 when we finally realized what it was doing:
After removing our additional metadata documents, the lease collection RUs are much better (note that we have several subscribers using the same lease).
Now we store our meta data documents in another collection, which happily sits at around 100 RUs, while leases, as you can see above, hovers around the same.
Bottom line: don’t store anything custom in the Lease Collection of the change feed because it exponentially increases the RU requirements.
using (TextWriter tmp = Console.Out)
{
using (var fs = new FileStream("Test.txt", FileMode.Create))
{
using (var sw = new StreamWriter(fs))
{
Console.SetOut(sw);
var workItemIds = new int[] { 1,2,3 };
var collectionUri = new Uri("http://yourtfs/server/");
try
{
using (var tpc = new TfsTeamProjectCollection(collectionUri))
{
var workItemStore = tpc.GetService<WorkItemStore>();
var teamProject = workItemStore.Projects["project-name"];
var versionControlServer = tpc.GetService<VersionControlServer>();
var artifactProvider = versionControlServer.ArtifactProvider;
var workItems = workItemStore.Query(workItemIds, "Select [System.Id], [System.Title] from WorkItems");
var allChangesets = new List<Changeset>();
foreach (WorkItem workItem in workItems)
{
allChangesets.AddRange(
workItem.Links.OfType<ExternalLink>().Select(link => artifactProvider.GetChangeset(new Uri(link.LinkedArtifactUri)))
);
}
var orderedChangesets = allChangesets.OrderByDescending(c => c.CreationDate).ToArray();
foreach (var changeset in orderedChangesets)
{
Console.WriteLine("{0} on {1:MM-dd-yyyy HH:mm} by {2} ({3} change(s))", changeset.ChangesetId, changeset.CreationDate, changeset.Owner, changeset.Changes.Length);
foreach (var change in changeset.Changes)
{
Console.WriteLine(" [{0}] {1}", change.ChangeType, change.Item.ServerItem);
}
Console.WriteLine("-----");
Console.WriteLine();
}
}
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
sw.Close();
}
}
Console.SetOut(tmp);
Console.WriteLine("Press any key to exit...");
Console.ReadKey();
}I had a conversation with a co-worker yesterday about when to create branches in TFS and the conversation reflected a confusion surrounding the use of branches. The coworker suggested that a new branch should be created each time code was being pushed to any environment because it’s the only way you can be completely sure the branch isn’t polluted.
To get the obvious out of the way, if a source control system “pollutes” a branch with no human intervention, get a new source control system. The system has failed at its most basic task. It is very likely this is not the case. It is probably how you are executing your branching and merging strategy.
Let’s take a typical branching structure: Dev > QA > Prod; Dev is the parent of QA, which is the parent of Prod. Changes are merged from Dev into QA, then from QA into Prod. You should never get merge conflicts when going from Dev to QA, or QA to Prod. Because of this, merging is clean and no “pollution” can happen.
How is this possible?
The only way a merge conflict happens is when a change has occurred in the target branch you are merging into which has not been integrated in the source branch. But - and this is the critical point - if you are following good merging practices, if a change must be made in QA or Prod, it is immediately merged into the parent branch(es). No exceptions! If I make a change in the QA branch, my next immediate check-in is a merge to the Dev branch from QA. I will resolve any merge conflicts with this merge, ensuring that my change is properly integrated in Dev. The next time Dev is merged into QA, it will already have this change, and so no merge conflicts will occur.