We are having a problem with the TFS connection. Is there any way to do merges between branchs with the TFS down?
I don't think so since TFS merges items by comparing the items from the source/target branch which at least one would be on the server.
It would make no sense to do so. If your TFS is offline, you cannot know whether you would merge the newest source code state. This would be highly insecure since it leads to code missmatch.
If you want to merge some code offline, do it manually with tools like WinMerge and update it to your TFS when its online again ;)
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 am used to working with Perforce and I really like the ability to be able to group checked out files under different pending changelists. For example, if I am working on two bugs at the same time and the changes made for them can be grouped separately.
I am unable to find this functionality in TFS. Is this supported? If no, what is the best practice around it?
I am using VS 2015 Professional with TFS Server 2015.
No, it's not supported with pending changelists in TFS for now.
To be a workaround, this is possible using the Suspend/Resume feature in Visual Studio 2012 and above. It will allow you to keep multiple shelvesets, associated to multiple workitems. Only problem is that you can't have all two bugs open at the same time, so you'll have to check them in one by one.
More detail info please refer this link: Suspend your work and manage your shelvesets
So in Git you can squash multiple commits into a single commit. So for example, let's say I checked in a change, but I realized I forgot something small, so I make the change locally and then I commit again. With Git squash you can merge those into one commit.
My question is does TFS have any sort of method for doing the same thing?
No. TFVC uses a totally different version control paradigm than Git; it does not support history rewriting actions like squashing and amending.
No, its not supported. You can't change the history of every changest in TFVC. If it can be achieved , it's a violation of the principle of source control.
And also you can't create a new changest then merge with the old changest, There have been a featured request in Uservoice and be declined by PM of TFS.
TFS to merge multiple, non-continuous changesets.
Thanks for the feedback on this idea. We have reviewed this feedback
and determined that we will not be able to complete this suggestion in
the foreseeable future.
Matt Mitrik TFS Program Manager
We have a branch called "Main". In July 2012 I created a new branch from this called "Phase 3" for the next version of our project. We have been working on this since then, but from time to time some other changes get applied to Main.
In May this year we performed a merge from Main to Phase 3 with some of those changes, and that was all fine.
Between then and now, we upgraded our TFS server from 2008 to 2012 update 3. (I wasn't involved with the "upgrade" but I believe it was an install on a new server with some kind of backup/restore of the data.) We've bit had any other issues with this.
Last week I tried to perform another merge from Main to Phase 3. I chose "selected changesets" because we have done a serious amount of rework in our phase 3 branch so merging changes across is quite difficult - so I wanted to do them bit by bit.
However, I was surprised to see that Visual Studio was trying to merge across changes from July 2011 - a good year before the branch was made (the very first changes made to this part of our project in fact.)
Oddly enough, if I view the history of the phase 3 solution I can expand it and see all these changes. So TFS appears to know that they have already applied.
I tried to merge some of the earlier changes across to see what would happened. The only changes it included were to do with items that had been renamed or deleted. For example, we had renamed our solution so TFS wanted to branch and merge a copy of the SLN with the old name. Or we had some images that had been subsequently deleted in both branches, but not at the time of this new merge.
So I backed this out and tried to merge everything across from May this year - i.e. just before our last merge across. This carried over a hideous number of changes - all sorts of things including regular merge/edit type changes. So I backed that out too!
We had created another branch from Phase 3. I have been able to merge between the two branches OK. I think it was created about a week before the TFS upgrade. But it's not experiencing the issue.
We have other branches that were taken from Main. These are experiencing the issue in that TFS is wanting to apply changes that it has already made.
I am using VS2012 update 3 to do the merge. I also tried VS2010 just in case but that does the same. Also a colleague has tried it and confirmed the same symptoms.
I don't think it helps that our phase 3 is so vastly different to main that merging anything across is really difficult.
Does anyone know how I can best resolve this? I'm a little worried about doing something I might regret later on!
I encountered similar problems when upgrading from TFS 2008 to TFS 2010. The issue is probably due to partially merged changesets. I.e. some of the files in the changeset have been merged, some haven't. Or it could be a branch move / rename situation. See the answer here for details of why a branch rename can cause this problem
In TFS 2008 if you attempted a merge, then unchecked files from the pending changes list. TFS assumed that you didn't want to merge the file ever again and on subsequent merges you wouldn't see those files.
In TFS 2010 or higher, the behaviour changes. If you uncheck files from the pending changes, on the next merge TFS will attempt to merge those files again. I think TFS 201x has the correct behaviour but its a pain that MS didn't highlight the change in behavior.
To check if this is the case, run the following from the command line
tf merge $/tp/main $/tp/phase3 /recursive /candidate
The /candidate switch tells TFS to give you a list of changesets it wants to merge without performing the merge. If you see any changesets in the list that have a * next to them, these are partially merged.
To fix it you have 2 choices.
Merge the files and resolve the conflicts, it might be worth merging on a changeset by changeset basis rather than trying to do them all at once. This will probably be a bit painful but once it's done it's done.
If you're confident that the phase 3 branch is correct then you can Merge using the command prompt. If you use tf merge $/tp/main $/tp/phase3 /version:c123~c456 /recursive /discard where c123 represents the oldest changeset you want to ignore and c456 represents the most recent changeset you want to ignore. The /discard switch tells TFS to update the merge history so that it thinks the merge has been done, but it won't actually perform the merge. This should remove the partially merged changesets from your list of candidates
If you opt for option 2 then you should do some analysis to make sure that you really don't want to take the partially merged changesets.
If you get to the point where merging is too difficult, or you just don't trust it.. then the only practical option is the "stomp over it with a new changeset". ie - do the merge manually outside of TFS and then commit your new, fixed changeset. then, kill the old branch and start again.
Not an ideal situation to be in, but your source integrity is paramount. Hopefully starting from a fresh branch will prevent issues like this in the future.
We're trailing the use of the built in bug tracking, and have written some integration into our helpdesk software that allows for escalation via workitems.
One thing I haven't found out how to do, is to merge all changes associated with a work item (say to go from dev branch to main) - I appreciate you can double click on a changeset in the merge dialog to view if it is associated with a workitem, and also that I can select individual changesets, and groups of adjacent changesets; but there doesn't appear to be any way to merge changes by workitem?
It is correct that you can't merge based on work items. It is probably not a good idea to do that anyway. It would be very difficult to make sure you get all the necessary changes needed for the main branch to build correctly. I would look into how you do your branching and a good starting point would be: Microsoft Team Foundation Server Branching Guidance
In TFS 2005 and 2008 the check in history will not be transferred between branches. You will get this in TFS 2010.
Merge changesets by workitem - https://tfsprod.codeplex.com/
Check out the ExtendedMerge feature.
Enjoy! :)