I know that I have not been posting in a while, and I hope to remedy that. I have been working on getting our internal team up to speed on using TFS as a full ALM tool and not just for source control. I am getting a lot of resistance on creating work items ( as this is a PM’s job !) but we are making progress.
I was off for the last couple of days and came back to a WTF moment. I noticed, upon opening my source control, that there were two “Main” folders. “Main” and “MainPreR1”.
WTF?
Upon enquiring it turns out that a change had been made to “R1” (legitimate) to fix a Bug (loose definition, but a definition none the less). Then the “Main” folder had been renamed and a new “Main” folder branched from “R1” and 2 new Features branched from that, leaving all the other existing branches to fend for themselves.
WTFx2!
If you are not sure what I mean, then let me explain. In order to merge from “F1207” into “Main” you would need to first merge it with “MainPreR1”, then merge it with “R1”, then merge it into “Main”. And thus you have just contaminated “R1” with something that is not in “R1” but should be in “R2”. On top of this the other orphaned features can’t take advantage of new features in “R2” without contaminating “R1”… messy.
As you can see from the screenshot on the right it is now under control, but it took the perpetrator the better part of the morning to get it sorted, and the are still putting the finishing touches to it (It is a good thing the do not let us have guns here in the UK). If you are interested, here are the steps that were performed to sort out this problem.
- Zip all content in “Fxx1” and “Fxx2”. To safeguard the dev work.
- Delete branch “Fxx1” and “Fxx2” from source control
- Check in everything…
- Delete “Main” from source control. coz it is the crap one
- Check in everything
- Rename “MainPreR1” to “Main”. Which is the way it should have been.
- Check In Everything… Now we are back where we started.
- Merge “R1” into “Main”. This is the action that should have occurred in the first place.
- Check in everything…
- Create Branches for “Fxx1” and “Fxx1”
- Check in everything…
- Check out “Fxx1” and “Fxx1”.
- Copy archived “Fxx1” and “Fxx2” over the top of new branch.
- Check in everything…
A long way for a short cut :)
Well, at least the lesson is learned…
Technorati Tags: ALM
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
Deploying Team Server
Discusses the challenges, costs, and benefits of implementing Team Foundation Server (TFS) for large development teams in a corporate …
Guidance - Branching for each Sprint
Explains how using a separate version control branch for each sprint in Scrum improves code stability, release management, and team …
Guidance: A Branching strategy for Scrum Teams
Explains an effective branching strategy for Scrum teams, covering best practices, common pitfalls, and step-by-step guidance for managing …
Guidance: How to layout you files for an Ideal Solution
Learn best practices for organising solution and project files in version control, including folder structure, naming conventions, and …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
Detecting agile theatre with real delivery signals
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
Estimating Better in an Overloaded System Is a Poor Man’s Strategy
High work in progress (WIP) causes delays and unpredictability; improving estimates won’t help. Limiting WIP and focusing on flow is key to …