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.
Related
I will start by saying this is probably a dumb question so apologies if I am staring at the answer but cannot see.
I have used VCS in the past primarily as a method of allowing me to revert my code if something goes wrong. I have always had a single lime of development. However I get into the usual trouble when releasing and starting the next version - dealing with bugs. So this time I decided to use branching (forking or whatever is the best name). I am a lone developer so I am the only one working with the repositiory. My scenerio is simple. I want to create a branch when I release so that I have a line for the released code and a line for the beta. I can then work happily on the beta. Now a bug comes in and I need to get back to the last commit for the release.
My question is what is the best way to get back that code in the IDE to work on it.
I have read that in Mercurial a simple way is to clone the repository including the working directory. This would give me two copies of the code base and I guess I can choose which one to load into the IDE. I would then use Push or pull to get the bug fixes from the release copy into the beta copy (I think).
I assume there must be another way however without cloning. How would I do that? I can guess at reverting to the last commit of the release code. Then I assume that loading the solution into the IDE would give me that. I am not sure where I would go from there when the code is done.
For the record I looked at a number of different VCS - I have used SVN in the past but wanted to go to a DVCS. I looked at Git, Bazaar, Mercurial and Veracity (and used Code-Coop in the past). You may think another tool would suit my needs better. Having tried the others however I found I could understand the way Mercurial works and the GUI tools such as TortoiseHg with the WorkBench and HgSccPackage (http://visualstudiogallery.msdn.microsoft.com/9bc074fa-9e1f-4ce2-a75d-b90e65f7475a) appeal
There are a lot of good documents and links here Introduction to Mercurial and I have read about different ways to branch that include using bookmarks and so on but they seem primarily targeted at multi member teams - which make sense of course
Many thanks in advance
You are mixing concepts a little, i guess you have SVN background ?
Just to answer you question, to 'get back the code in IDE' you will need to 'update' to a previous version. But this is considering you already have cloned the repository. Is your question about how to clone.. ? As you ask, there is no other way without cloning first. Cloning is the first step towards having a HG repository local. After clone, you can commit and push changes or pull and update.
To expand the answer even further and given that you are going to use Mercurial, here is what you should do:
read this : http://hginit.com/ - great HG (tutorial) by Joel Spolsky him self ! An introduction into HG and the concepts. You will need to understand this very good, since right now you are doing a lot of guessing, assuming and thinking :) HG/Git is different from SVN and in the begging the concepts might be hard to understand and to get used to.
for your project and regarding your question, have a branch called 'dev' or 'trunk' or 'version X' etc where you will commit all new changes.
have a branch called 'live' etc that will represent the current 'live' version. This way, whenever you need to revert back in time to the live version and to do a quick fix on it, you will 'update' to the tip of that 'live' branch, discarding all local changes (after you have committed to trunk! of course).
when putting a version to live, you will need to (assuming all changes are committed !) : update to the live branch then MERGE the version X into local (local being live ). This will include your versionX branch into live - it's what you need at this point. Then, either update back to version X branch or create a new branch - version X+1. This will take care of the versions and keeping the branches separate.
since you are using VS - install http://visualhg.codeplex.com/. HG source control integrated into VS.
I assume there must be another way however without cloning
Yes. You can use (named) branches inside single repo (I prefer HgSccPackage in VS), update to revisionbranch head, change, commit, merge
BTW, branching with bookmarks/clones/branches work the same (good) way for any size of team - it's a matter of taste
My scenario is pretty straight-forward. I am working on a long assignment locally on my computer, working off of a code branch from TFS. Along comes the boss, and I need to push through a bug fix. Is there any clean way to change contexts? This long assignment has updated a lot of files, and I want to make sure I implement the bugfix from a clean slate.
If I were using Git, I know what to do: create a new branch from main, fix bug, check in, change back to previous branch, but TFS doesn't really work that way. Any ideas?
If you don't want to commit the changes you 're working on yet, your first step is to shelve them - that's pretty straightforward.The next step is to decide where you 'll be implementing your urgent request. This depends on
How you have set up your branching scheme in source control (see here for a great resource ), &
The line where the error was reported
'Boss'-bugs tend to be reported from Release-Lines, taking this as a given you would have to:
Identify the latest changeset that corresponds to the version your problem was reported
Track this changeset to a version in the branch you can work on (I suppose you can't make changes directly on your release line, right)
Make a branch & implement the change. Your build-environment should ensure that all tests & checks ensure that your issue is fixed & that no others have emerged.
Your next challenge is how you 'll propagate these changes to a new Release - This greatly depends on how you ship software to the customer (Hotfixes? Patches? Service Packs?), as well as the severity of the issue.After you 've settled everything back to normal, unshelve & continue working on your long-term task.
Where I work we have a long build process that includes more than a dozen modules. I work in module [A], and it often happens that code is checked into module [A] at the same time as code is checked into module [B] and [C] (this happens when a developer is working on cross module items).
The problem is that I periodically get latest on my module (necessary for other reasons relating to dev database schema concerns) and the new code can reference code in other modules ([B], [C], et..) which hasn't been built yet in our daily build. I can pull down modules [B] and [C] and build them myself, but due to the configuration involved in our build process...this could take hours.
My solution so far has been to comment out the code which contains the functionality that isn't yet available, and then try to remember not to check those comments in when I am done with my work. Is there a way to mark a file checkout (or a series of file checkouts) as temporary?
Short Version
How do I mark part of my changes so that when I go to check-in that those changes (and not the rest of my changes) are ignored / undone?
--Edit
I can't use branching because of sync issues involving our dev database and our home brewed ORM.
Short answer: No. Sorry.
As a tip it sounds like you need to consider your branching strategy. You may be best off creating a branch for your work so that you can work in isolation and then merge back your changes into the main branch when your work is complete. Just remember to pull from main branch regularly after the build process completes so that your final merge is relatively pain free.
The answer I found was to use a TFS feature called cloaking. I can cloak a folder containing the offending code, and then I won't mistakenly check in code changes that I am trying to ignore. It is still somewhat cumbersome in that I need to make sure to turn off cloaking once I am done, but at least I wont be erasing good code on accident.
Isn't this what TFS Shelvesets are for? You can put all your changes into a shelveset to be commited later, then work on the existing code as things stand.
Shelvesets are a good way to have your changes waiting if you aren't ready to fully commit them yet.
Here is my situation:
The project I'm working on right now
uses a version control system
(Microsoft Team Foundation) that's
hosted and managed remotely by the
customer. I am in charge of doing a
massive refactoring/bugfixing after
somebody who left a horrendous mess of
code behind. Due to several reasons
that I won't detail here* I cannot
commit to the version control my
incremental changes while I patch
things up; and there is no way I can
be given a separate branch there.
Here is my question:
I want a version control system that I can use locally. I can't just keep doing "zip source folder and backup it". I want a track of changes. I want commit messages. I want to see what I did and when and why in a couple of months. In a pinch, I'm tired to rely on VS 'undo' command and to leave comments myself tracking what I'm doing and how it was before.
Here is what I would do:
I'd install mercurial/git locally and start versioning my own directories.
Problem is, I am not sure this is the best way. Hints? Ideas? I am not familiar at all with either Visual Studio or Team Foundation and can't seem to find my way around with them (I don't know how things are 'named' so I don't know what I'm looking for). Is it possible, using such tools, to do what I have described?
*basically the customer doesn't necessarily have to know that our lead developer quit in anger and left the most horrendous code mess I've ever seen behind me; that at least 3 people 'tried to fix' his code in a rush to patch bugs; that this ended up in a single class with a 400+ long method including a single 'for' loop, at least 5 places where code is repeated-but-not-completely, unused logic, wrong comments, while(true) loops, and increasing the 'for' counter in the loop body to look-ahead into an array list. Basically, we hope the customer won't notice what's happening and if they do we can fix it when they whine.
The usual approach is to:
"git init" directly in the directory you want to manage locally
add a .gitignore in order to not add any VCS-specific data or directory
git add .gitignore and commit
git add .
commit
That way, you have a local repo you can then clone, make branches, patches, ...
(I do it for ClearCase views for instance)
A similar approach, with similar commands, is valid with Hg Mercurial of course.
Currently I am working on a project that uses TFS as source control. I am in the middle of implementing a piece of functionality, but am blocked by work that needs to be done by outside resources. Since the functionality is not fully complete, I can't check in the changes without breaking the build. So instead of waiting a couple days while the blocking work is finished, I want to work on some defects.
To do this work in isolation from my other changes, I am working the defects in a second workspace I just created.
After using a second workspace to isolate my changes, a coworker asked me why I didn't just shelve my changes. After doing some reading on shelving, it looks like this is preferred solution to situations like mine. My question is what situations, if any, would you create multiple workspaces and what situations should you use shelving? There are some posts about shelving, but I don't see very much on the subject of workspaces.
By the way, I got the idea for creating a second workspace here.
A new branch would probably be the best way to go. But, to answer your question, one of the key differences between shelving and just using a differnet workspace is that when you shelve, you push your code back to TFS, so it is backed up. Whatever is in your workspace is just what you have on your machine -- if you lose it, it's gone.
We use branching a lot in my shop, and as a result, I haven't seen many uses for shelving.
However, I have found one case where it has been very useful to me:
I often bounce between 2 different development machines (one at the office, one at home, connected via VPN). If I am working on something, and I want to transfer it from home to work, or vice-versa, I often use shelving. I can shelve it from one machine and un-shelve it from the other. I do this when I am in the middle of a change, and checking in would break the build or otherwise interrupt other developers.
You are talking about two completely different concepts here. When you shelve code, you are saving it to TFS, but not checking it in to any particular branch. Creating a different workspace just sets up a new local folder on your development machines and saves the files in your branch there. When you do a check-in, you still could have conflicts.
Why not create a new branch of your code. You can work on that branch and check in without stepping on anyone else's changes, because you are checking in to your own branch of the code. Then, when you have completed your changes, and others have completed their's on the main branch, you can merge your changes into the main branch.
Shelving is the ideal option. Shelving allows you to make changes en masse in TFS outside the regular build, and retrieve them later by name. Multiple workspaces is not a solution for what you're doing. Multiple workspaces are good if you're maintaining different versions of a product and need to work on them, e.g. let's say you have a 4.0 and a 5.0 product and need to apply a security fix to both versions. Shelving is great when you want to make changes but not commit them immediately.