In TFS I'm performing the following action.
UnShelve Pending Changes--> right click a file in a ShelveSet --> select Compare --> There are three choices:
With Unmodified Version
With Work-space version
With Latest version
What is the difference between 1 and 2 ?
Basically, the options are broken down as follows :
With Unmodified Version - The Shelve File will compare the files with any pending changes to the corresponding files prior to the shelve being created.
With Work-Space Version - Typically this will compare your current code running on your machine to the code at the time that you checked out the file. Basically allowing you to see what changes you have made in the current checkout.
With Latest Version - Compares your code to the most recent code that has been checked into TFS.
So the difference between the first and second options would be that with the Unmodified choice, you would be comparing with any changes that occurred prior to the shelve being created and your work-space choice would display the changes that you had made in the current checkout.
Related
I have source code in the main. From this main i created a branche development. After changing the development branche i want to merge these changes back to the main. When i do this these changes are marked with [Merge,Edit] while i expect [Merge]. Can anyone explain this behavior?
(merge) means merge with no real change
(merge,edit) means merge with a change on the file in target with contents from source.
Nice readings on: What does it mean when Source Control Explorer shows both branch and merge for a changeset?
Unfortunately no msdn pages...
The merge status means that the revision contains a merge from another branch.
If a particular file is diffrent in the two branches, the file will have the status "merge, edit" because it is both merged from the branch and changed content.
After you perform your merge and check in it, a Conflicts Window appears.You must solve the confics of the file which has "merge,edit" status before check in.
I have a Visual Studio solution and am using TFS for version control.
When I've made a bunch of changes to my working copy of the solution, the Team Explorer window will show me all the files that I've changed, and allow me to compare my version with either the workspace (original) version, or the latest version in TFS.
However, before I check in my changes, I first want to integrate any changes that have been made (by other people) to the latest TFS version since I got the source from TFS.
I could do a Get Latest Version and hope for the best. However, I would generally prefer to know what will be changed, and have the opportunity to look in detail at those changes, before overwriting my local files.
Is there a way to either compare my workspace (original) version against the latest version in TFS, or to see what the effects of a "Get" will be before I actually execute it?
To be useful, this would have to be a at a solution level - I would not want to have to go through each individual file.
Use Compare... and select Latest Version. That's best executed from the commandline or the Source Control Explorer.
If you compare "Latest Version" (remote) with "Workspace version" (local), then it'll tell you what has changes on the server since the last get-latest.
If you compare "Latest version (remote) with "Latest version" (local), then it'll tell you what has changed both locally and remotely.
The command line is your friend you can use the /preview switch to see what will happen if you do the get
tf get $/MyTeamProject/MySourcePath /recursive /preview
My goal is to have the "latest version" of my code be that of an existing changeset. I choose Roll Back, and roll back to that specific changeset, but my code doesn't change to reflect the changeset's code. Additionally, I tried "Get Specific Version" for that particular changeset, and while my local code changes to the changeset's code, the column in TFS that says "Latest" shows "No" for those files that were reverted - see screenshot below. The screenshot below is a result of "Get Specific Version":
QUESTION: What's the difference between "Get Specific Version" and "Roll Back"? If my goal is to essentially change my current code base to the code base from an existing changeset, and have that as the "latest version" (for TFS reasons - I'm trying to deploy out to our web server using TFS, but since TFS "doesn't have the latest version" - see screenshot above, it uses the current, latest version which is not what I want it to use - I want it to deploy from the code base for the previous changeset), how can I do that?
If you "Get Specific Version" you are changing your local workspace version to that of a previous version on the server. This does not affect the latest version on the server. (You could, of course, check out that path and check it in, which would affect the latest version on the server.)
If you "Roll Back" you are changing the server version. Depending on how you perform this action, you may not be changing your local workspace version. If you do a "Get Latest Version", you will sync up to that latest version.
If you simply want to build/deploy an older version of the code the default build templates allow you to specify a changeset number (or date) and force it to use an older version of the code.
If you really do need to change the "current" code in TFS, then you can do rollback. But it sounds like your understanding of Rollback is incorrect. It's not "rollback to this changeset", rather it's "rollback the changes contained in this changeset".
So if your latest version is v9 and you want to go back to v5, you need to rollback changesets v6-9. You can highlight all 4 of these changesets and roll them back all in one operation. Then check-in.
This will give a better experience than trying to do a get on an older version then check-out/check-in. The history will more accurately reflect what you did, and the conflict resolution dialog won't try and do the wrong thing (as it would if you did a get then check-in/out).
I have an iOS project under Subversion source control and I am using Cornerstone as my SVN client. (I have also tried using XCode for this as well)
I've had numerous problems merging branches, and hope someone can help!
In the simplest test I have done, I have:
Created a new branch from the trunk
Made one small text change in one file in the new branch
Immediately attempted to merge the change back into the trunk from the branch.
When Cornerstone analyses the merge contents, it reports lots of tree conflicts and newly added files.
Other (potentially) relevant info:
I am the only person working on the project at present, so there are no other changes being made.
I have tried merging from branch-branch, trunk-branch, branch-trunk all with the same result
The server is using SVN v1.4.2, my client is v1.6.17. I am suspecting that this may be the cause, but am looking to get this confirmed if possible.
Thanks!
It appears that the problem is due to the server being v1.4.2.
I deleted my existing working copy and checked out a fresh copy, ensuring that the SVN version was set in the check-out dialog box to 1.4.
Now, when I attempt a merge, I only get the options to "Cherry Pick Changes" or "Advanced Merge". The "Synchronise a branch" or "Reintegrate a branch" options no longer appear, so these must be options not supported on 1.4.2 and be the cause of the conflict explosion I was seeing.
In summary, to merge between my branches it appears that I have to select the specific revisions that I wish to merge.
I made a boo boo with a with a Visual Studio 2010 project on TFS2010, and instead of spending hours trying to fix it did i decide just to go 2 revisions back, and continue from there, which worked fine.
But how can i now make my local version the current revision? When i try to commit i just get a version mismatch error.
Open the pending changes conflicts dialog:
Top Menu -> View -> Other Windows -> Pending Changes
If you want to make your local version the current version. You will be presented with a list of conflicts.
For every conflict select: "Keep Local Version"
Here is an example of what your screen will look like notice the "Keep Local Version" option to the right of the item in question.
Check it in and you should be good to go.
You check everything out with your local copies and during check-in you will encounter conflicts. You will resolve them by overwriting server version and accepting your local copies.
Voila, your local copies are latest now.