The title more or less sums it up. We use MS TFS as our version control which integrates to eclipse via the teamprise plug-in (Corp standard, primarily an MS shop. I wish we could just use SVN, because frankly the Teamprise plug-in is rather atrocious). Suppose that someone commits a file with changes that we want to keep, just not yet. If this commit is version 3, is there a way to tag version 2 as the latest version with out checking version 2 back in as version 4, thus meaning I will later have to check version 3 in as version 5, rather than just retagging 4 as the latest at the point when I want to use it?
views:
257answers:
2In TFS the "latest" for a particular path is determined as the last file that was checked in for that item (with any merge conflicts resolved). I'd suggest a few things that might give you the workflow that you would like:
- Would working in a branch help you at all? Then you could decide when to merge changes in from the mainline of code into the area that you are working on.
- Teamprise supports the Sync feature in Eclipse, so you can right click on a project and select "Synchronize". That will show you your changes compared to the latest version on the repository. From there you can compare those files with the latest version and see which ones you would like to update and which ones you would like to leave at your local (workspace) version.
- If you do a "View History" on any file or folder you will get a history of changes that have occured with that file. You can then get any particular version you would like by selecting "Get this version" from the history view.
- If branching doesn't work for you then you might want to try labels. In TFS labels are like "tags" and are editable. Using the mechanisms (such as sync and get from history) you can decide which versions of files that you would like to have and label these with your particular label. You can then do a "Get Specific" and add your label name if you so wish.
If what you are asking is "is there a way to easily rollback changes" so that you can say that version 4 or a file had a change in that you didn't want so you would like to rollback the code for everyone to version 3, then I'm afraid that the only way to do this now is to check-out the file, get the older version (from the history view) and then check that file in. When released, TFS 2010 is due to have native support for Rollback as a version control operation and Teamprise should be supporting that as soon as it is available in the server.
Additionally, I would add that I personally get a lot out of working with tools like continuous integration (and TFS 2008 has some excellent support for CI out of the box, but other open source CI servers such as CruiseControl and Hudson also support TFS). This, along with use of the fact that check-ins to TFS are atomic, means that developers can learn to trust that the "latest" version of code is always good. It encourages developers to do a get latest frequently and regularly check-in changes.
It is perhaps because of these ways of working that we may have missed out some functionality from Teamprise that could possibly help you more and we could well be just assuming that people want to Get Latest so that is what we are making easiest. If you do not feel that Teamprise is adequately supporting you in accessing the features of Team Foundation Server then I would love to hear from you. My email address is [email protected]. Alternatively you can contact our support hotline at [email protected], visit the Teamprise forums at http://support.teamprise.com or give our support team a call on (217) 356-8515, ext. 2. We love to get feedback from our customers to make the product better, and it is customers that do not feel well served by the current tools that often give the best feedback.
If Rollback is a feature that is highly desired by you, then please let us know.
Martin, thanks for the responses. However, it seems that most of what your referring to are features I'm aware of and not what I'm looking for. Basically the scenario I've run into/am envisioning is where a given feature is targeted for a given release and is developed. Then later, for whatever reason (could be a technical reason, a business reason,etc), that feature is pushed out to a later release. In this case, I want to be able to keep the changes made for that feature and simply rollback to the previous version without having to perform 2 more check-ins (one to rollback and one to roll forward again). I want this because I want to always be able to get and trust the latest version.
We do use branching to manage versions(1.3,1.4,2.0) but not for individual builds/releases. Frankly, I don't think this is something I would want to have to do because of the overhead cost of doing a branch and a merge, and I'd be surprised if this is what you are recommending.
Essentially though, it sounds as if what I want will be supported in TFS 2010. Thanks again.