In TFS, what is the best way to mark dead branches? Do you move your branch? Branch release it? Delete it? Rename it? What problems have you run into for each of these approaches? What are the good points?
It would be nice if there were a simple interface solution that would simply mark or filter the current view if a particular branch was tagged as dead. That way you wouldn't have to do something permanent like rename or delete a branch . . .
Deletion isn't permanent, so I'd go with this option.
You can then opt whether or not to view deleted items in SCE (Tools -> Options -> Source Control -> Visual Studio Team Foundation Server -> Show deleted items in the Source Control Explorer).
And you can choose to undelete the branches if necessary.
After merging back to the trunk we do delete them much easier than having to cloak them in workspaces, see Ian's about deletes not being permanent.
We move our dead branches to an archive area of the project.
Because the branches are cheap in
TFS, there is not a space concern.
Deletion can cause bizarre problems when someone attempts to add something new with the same name.
Moving them enables continued use of features like Annotate (a.k.a. blame), which allows drilling through branches to see a full history of changes.
Related
Recently, one of the junior developers made a check-in to a large MVC SOA C# application, to both the client and service side, which makes the project unbuildable. Their check-in added spurious dependencies as well as removed required files, with something like 900 files in the project affected.
In order to keep the project moving forward, I was instructed by management to simply obtain the project from the changeset prior to this check-in in TFS and and then apply all changesets after the bad check-in going forward, since we though a release would be urgently needed.
As the weeks have passed, however, this approach is getting untenable. Is there a way to do one of these two things in TFS?
Either
remove a changeset from TFS without removing the changesets that come after it?
or
Automatically get all of the changesets in TFS for a solution except for one specific changeset.
remove a changeset from TFS without removing the changesets that come after it?
According to the document Roll back changesets:
A changeset is a permanent part of the history of your
version-controlled items and cannot be undone or removed. However,
you can roll back the effects of one or more changesets.
So, we could not remove one specify changeset. Just like James said, we could roll back the bad changeset. But it will also remove the changesets that come after it. As workaround, you can check the Changeset details for that specify changeset. Then ask that the junior developers remove his code, then check in the delete changeset.
Automatically get all of the changesets in TFS for a solution except
for one specific changeset.
There is way to find and view a TFS changeset by comment text:
tf history $/ -r | ? { $_.comment -like '*findme*' }
Check the this thread for some more details.
But there is no such out of box method to exclude one specific changeset in the text, we need to write our scripts like, batch, powershell to except it from the text.
Hope this helps.
I have a Team Foundation Server 2013 code structure like follows...
$/TeamProject/Application/AllTheCodeFiles
...but I'd like to refactor to have...
$/TeamProject/Application/Trunk/AllTheCodeFiles
Which will allow me to implement a branching and merging strategy moving forward by creating "Release" branches at the same level as "Trunk".
If I try to either branch or move the Application directory into Trunk, I get the error message:
The target item $/TeamProject/Application/Trunk cannot be under the source item $/TeamProject/Application.
So, here's the process that I followed, it feels wrong and I'm guessing that there's a more efficient way of doing this.
Rename $/TeamProject/Application to $/TeamProject/Application-trunk
Create a new $/TeamProject/Application directory
Move $/TeamProject/Application-trunk to $/TeamProject/Application/Trunk
After doing this, history is associated with $/TeamProject/Application not $/TeamProject/Application/Trunk. My question is this, someone who knows more would do this in what manner?
I've just gone through what I would do on my Test TFVC and things seem OK version history wise.
Here are the steps:
Start with $/TeamProject/Application/
Create a Folder at $/TeamProject/Application/Main/ (TFVC Convention - Trunk is SVN)
Check in pending changes.
Move all files and folders from $/TeamProject/Application/ to $/TeamProject/Application/Main/
Check in pending changes.
Convert $/TeamProject/Application/Main/ to a branch.
Here's the history of a file that was added (C58) and edited (C59) before the move (C62) and then edited (C63) after the move:
Is it possible to view history and compare with shelvesets? We are investigating the possibility of using shelvesets instead of check-ins. From our initial investigation it seems we cannot view history like we do for check-ins.
We are using Visual Studio 2010/TFS 2010.
From http://msdn.microsoft.com/en-us/library/ms181403(v=vs.90).aspx
Section: The Difference Between Changesets and Shelvesets:
Unlike a changeset, a shelveset is a non-versioned entity. If you or another user unshelve the items of which a shelveset consists, edit several files, and reshelve the shelveset, Team Foundation does not create a new version of the items for future comparison and maintains no record of who revised the items, when, or in what manner. The original shelveset is completely replaced.
So, no, you can't review history. I am unsure on methods of comparing shelvesets. You should also read that entire section (The Difference Between Changesets and Shelvesets) as each item in it is a strong argument to not use shelvesets in the place of changesets.
I also cannot think of any reason why using shelvesets instead of changesets would be desirable, maybe you can list the reasons why you all were exploring this path. Just think about not being able to track changes, that alone should be a deal breaker (of course, shelvesets not even being versioned should just about do it)..
Like it says on the link posted by dugas, shelvesets are built more for...well, shelving things. For example, on the project I am working on right now, I did a shelveset for some refactoring changes I was in the middle of because something unrelated broke and I needed the code back to the original non error-filled version. I also use it for when I'm in the middle of attempting something and want to have a backup but I don't want to check in code just yet.
There's no versioning on shelvesets, but it is possible to compare code in a workspace, to the code in a shelveset, without pulling the shelveset files.
Pull the versions of files you want to compare the shelveset contents to, into a workspace
open the solution in that workspace
File >> Source Control >> Unshelve Pending Changes...
find the desired shelveset and bring up its details
On each file in the Shelveset Details window, you can right-click and select Compare >> With Workspace Version...
TFS will pull the shelveset file to a temporary location, show the diff, and then (?) clean up the temp file after you're done.
You'll be comparing the shelveset file contents, to the contents of the files on the local disk in this workspace. If changes were made to both files, the compare won't be able to tell and will indicate all those changes. However, you can compare the selveset version to its original (Compare >> With Unmodified Version..), to see all the changes that were made just to the shelveset file. You can also find out the changeset that was the base for the shelveset file (Properties..), and see what changes were added to the workspace version since that common base changeset.
There's no tree compare though, and this may require the TFS power tools to work.
P.S> I don't recomment trying to use shelvesets in place of checkins like this. If there's one thing I've learned over the years, it's not to fight Microsoft's designed-in workflows -- you do things their way, or you find a different tool. Microsoft doesn't intend you to use shelvesets this way (they want you to use changesets and a branch), and if you try, you'll constantly be fighting Microsoft's designed-in workflow.
You can use shelvesets for peer code-review before committing them to the repository ... and also for parking commits before going through a gated build process.
They are not suitable for anything other than "quick shelving" of work - use branching if you want to have multiple parallel work streams.
The team I recently joined has the following TFS branch structure (abstracted):
Main
Foo branched from Main
Bar branched from Foo
I need to blow away Bar and essentially re-branch it directly from Main, rather than from Foo. I do not need to maintain the existing revision history in Bar.
The seemingly logicial and simple thing to do would be to simply delete Bar and re-create it as a branch from Main, however I ran across a blog post from one of the TFS MVPs indicating that deleting/re-creating a branch using the same name is bad ju-ju.
So... what should I do? Is there a way to re-target a branch without deleting it? It's worth noting that the name of the Bar branch needs to stay the same, for various reasons.
Re-targeting branches is not easily done in TFS. I think branching and merging is very, very limited in TFS compared to other VCS-es.
We have on several occations done what you are describing, without noticing any problems. However, I cannot guarantee that you will avoid the problems. Is moving to another TFS project an option? Then you can merge Main to the new project, and branch out a new "Bar" there?
Probably not an option...
You have a couple of options, if you want to keep bar, but change it's relationship with main you could reparent the branch. First you need to do a baseless merge from main to bar
Tf merge /baseless $/teamproject/main $/teamproject/bar
Check in the pending changes.
Once the main and bar branches have a merge relationship you can reparent the branch in source control explorer. Right click on bar, select "branching and merging" and then "reparent". You should now be able to select main. See this blog for more information.
If the history isn't important then you could "destroy" the branch rather than deleting it. This should avoid the issues described in the blog you mentioned. Use the "tf destroy $/teamproject/bar" command line.
As the name suggests destroy is permanent so use with extreme care, once you've destroyed the branch then you shouldn't have any problems re-branching.
We have a trunk in TFS that everyone works off until we have a need to branch. Our last project was a large feature that required a branch. Now that the development has been completed and the changes have been merged back into the trunk. What should happen to the development branch?
Should I delete it? Mark it as read-only somehow? What about cloaking and locking?
You can make a branch read-only. You just need to remove the check-in/check-out permissions from the appropriate groups. Note that it doesn't look any different on first blush, but when you attempt to check out a file, you'll be prevented.
I always end up deleting the branch. It's "deleted" but there's nothing preventing you from undeleting it (which is different that destroying) or looking back at the code. It doesn't actually go anywhere unless you go through the effort of destroying it.
In addition, if you have a nice tool like Team Foundation Sidekicks, you can still see all of the branching history, even if it's been deleted.
You can, as #Ray says, just leave it, but if you do that over the course of a dozen or so branches, things become a bit unwieldy to manage. If the branch is dead, and you've merged the code into mainline, do you have any purpose for keeping it around aside from "just-in-case."
If so, just delete it and dig back through it only if you really have to.
Just leave it. :) You can delete the branch but it will still remain in the repository. It really is a decision that you and your team can make to follow your source control guidelines.
On a side note, there is no read-only option in TFS, you can only leave it, delete it or run the TFS destroy command to permanently remove the branch.
There is a Read access control permission. If you set Contributors to "Deny", it should override any "Not Set" or "Allow" permissions. You can set it in Source Control Explorer by right-clicking on the folder and going into Advanced | Security...