I am much more used to SVN than to TFS so I am unsure on how to do this.
I have some project that use to be fast in some data around 10 days ago and now I tested it again on that data and it is much slower. So I would like to go to each of the versions of the entire project (not just a file) between 10 days ago and now, without losing any version.
So basically: how do I checkout some version by Changeset number, run it, then checkout another one and so forth without ever loosing any of the versions? Specifically, every time I go to previous version I may want to change stuff in the code (for testing further) and I want this changes to be lost every time I checkout another version (because I don't want them to remain anywhere).
Thanks
In Source Control Explorer, right click on a folder and choose Get Specific Version. It's under an "Advanced" menu, if I'm not mistaken.
Related
We made a lot of changes to our code and don't want them any more. We would like to roll back these changes to a changeset from a couple of days ago. However, we are having considerable trouble doing so. We have loaded the version we want to use. How do we go about promoting this version to be the Latest Version on the TFS server, so that our other machines can pull it?
Thanks
Open source control explorer, right click on the folder that you want to roll back, and choose the "roll back" option.
I am using VS2013 TFS, my scenario is
1'st version of code checked in TFS and released. (Local Path is
C:\Development\DEV )
2'nd version coding started and not completed.
Now client is asking issue fix on top of first version ? how to do that ?
The same issue fix should be included in 2nd version also. how to do?
Assuming you have no branches yet, it goes something like this:
Get History on your main (v2) branch and work out the changeset or date/time at which you originally built v1.
Right click your main branch (v2) and create a new branch (for v1). Choose "from a changeset" or "from a date/time" and enter the information from the first step to identify where (or rather when) the branch should be taken from. Commit this branch. You mow have two separate independent branches, with the v1 branch using the historical code you had for the v1 release, and your main branch still containing v2.
Now you can fix the issue, in either branch. You will need to use the Source Control explorer to map both the branches into separate folders your PC so that you can work on them. (If your source code is not relocatable then you will have to switch between the branches by remapping them to the same location. This can be confusing but not too difficult if you do things carefully and make sure you get a clean copy of a branch before you start working on it. The pain of this is a good way of learning to make your code relocatable the next time :-)
Now you need to replicate the fix in the other branch. If the branches are quite different you may find it easier to just write the fix a second time in the other branch, or you can right-click on the fixed branch and Merge into the second branch. TFS will do as much as it can for you but you will then need to resolve any merge conflicts to apply the changes you made for your fix to the second branch without breaking anything. (This can be quite tricky, so take care, and if you are unsure remember that you can undo your changes and re-start the merge at any time)
Once you have finished the fix and tested your merged code locally, diff it once more against the previous/workspace version to be sure that you can's see anything you might have screwed up in the merge, and then check it in.
Finally, if your release needs to be built by your build server, then you will need to point your build system at the v1 branch to get it to build the (fixed) v1 version for a new release (for a once-off build you just have to redirect your source control mappings for the v1 branch so that the build server gets from v1 instead of v2 when it 'Gets' the source code from source control, and when you are finished, remap the source back to the v2 branch)
As long as you think through each step and take care, it's fairly straight forward. But if you have never done it before, I suggest you work through each of the steps above and do some searches to learn more about how to branch, how to map source control folders, and how to merge.
Branching and merging is a complex topic and there are many patterns that you could follow. Without knowing more about your requirements it's impossible to give you good advice. You need to consider things like: How many clients consume the code. Is this for a shrink wrap application with multiple versions available concurrently or a production system where there is only 1 version "live" at one time. You'll also need to take in to account how you test your code (environments etc) and what kind of build process and deployment process you have.
The best advice I can give you without more information is to read the ALM Rangers guidance on TFS version control. Then come back with more specific questions. Also, keep it simple, don't over think it or you'll get in to a mess.
I pressed Alt-E which I mistakenly thought was Merge Changes In Merge Tool, however, that was actually Keep Local Version. Is there a way to go back? Is there a way to find out what was merged, as in what file? Ugh! :(
I have completely stopped working in case I erase something of importance.
I'm using MSVS 2013 Professional.
Here's another possible approach.
If you know what version of the code you started with before you started making your current batch of changes, you can grab a copy of your local workspace files. Then Undo all your Pending Changes. Then delete all the files in your local workspace (in Windows explorer). Then do a Get Specific Version to get back the old version of the files from where you started, then copy-paste in your updated files from your backup copy. Then do a Get Latest. This should retrigger the Merge process.
I don't know a great answer to this problem, but I do know one thing you can do (I hope you don't have a massive amount of pending changes, or this will get tedious).
The problem is that TFS thinks you have now merged the server changes (other devs changes) into your workspace, even though you told it to basically toss them. If you try to check-in now it will blow away other developers changes in TFS.
What you can do is go through each file in your pending changes window, and do a Compare With Latest Version. This will show you the differences between your local file, and the file in TFS. You will notice two types of differences:
the changes you made which you can just skip past.
Changes that other devs made and are on the server, these differences will show up as though you have deleted/undone that code locally
For the changes that other devs made, you will have to manually reapply them in your local workspace before you check-in.
I want to use a versioning system to back up and track my changes but I'm too lazy to check out/check in, merge, commit, etc. I don't want to branch, fork or anything else. I just want to be able to see what files have changes and what my Main() looked like last week.
So I'm looking for an application that will simply take my Visual Studio projects folder and back it up in such a way that all prior versions of the files are preserved so I can not only have a backup, but I can easily see how the file looked at some point in the past without me having to explicitly put it in a repository, update/commit/merge/etc.
Basically what I'm looking for is dropbox's functionality but on my local machine and without the 30 day limitation of prior versions.
Does such an application exist?
As AlexC stated, I highly doubt that the little bit of work you save by not using a version control system explicitly is worth the drawbacks, but anyway:
Simplest idea: Just write a wrapper script that checks out the HEAD of your repository, starts Visual Studio and commits everything to version control after you close it.
Alternatively, just trigger commits every hour. With most VCSes, non-modified files won't show up in the listing of modified files.
We have multiple developers working on the same code base. We also are trying to use SourceSafe (6.0)
When one developer makes code changes to their local copy, we note it in a list of changed objects for this release.
When it's time to compile our next release, we open the "master" copy, update all the changes from SourceSafe to the master copy, then compile.
At this point, all the other developers code is now out of sync with the master copy, and we need to get all the changes pushed downhill to all the developers local copies, so we're all looking at the same version of source at the start of a new release cycle.
Is there a way to have SourceSafe update the local copies with the latest changes, or do we need to do it manually basaed on the list of changed objects (which is what we're doing now...) Please don't tell me to use "Get Latest Version". It only works on one file at a time, and is the process we're using now anyway.
I believe your process is simply incorrect. When your devs get in, just have everyone Get Latest. When your developers want to make a change, have them check out the file. This way, it's one dev working on a single file at a time.
If you want multiple people working on the same file, I'd switch to subversion (there is a vb plugin for it).
There is a reason why the SCC tools work the way they do - it's been tried and tested over the last 20 years.