Undoing a changeset?

Undoing a changeset?

• meo1985

  Keith,
  
  To add to my comments in repsonse to Carl's feedback, rolling back a changeset (revert as we called it) will certainly be considered for version 2.  At this point, we don't know what will be in the next version, of course.
  
  The issues with working offline have to do both with TF's lack of an offline mode in version 1 and the source control integration in the core of VS.  We hope to make it less painful by RTM, but we won't have a true offline mode in version 1 (e.g., do source control operations while not connected to the server).
  
  Buck
  
  

• Yehuda Tuvia

  Undoing a changeset - yes, that appears to be a major missing feature, unless it's hiding somewhere.  I'd like to see a "Rollback" in the context menu for a changeset as it appears in the history window.  This should perform (effectively) a three-way merge using the changeset as the "base", the previous chageset as the "yours" and the tip as the "theirs" revisions.  Perhaps this can be done using a merge - merging a branch with itself.  [Update: It's not possible to merge a branch with itself, at least not from the IDE].
  
  Full path - while it's not quite as explicit as you'd like, if you hover the mouse over a tab on a document it will show you the complete path in a tooltip.
  
  
  

• scwoods

  What do see as the holes in TF source control
  
  Buck
  
  

• Zustiur

  We had a rollback command in the original spec for Team Foundation (we called it "revert") but we cut it from V1 to bring in the schedule.  It'll be there in a future release, I'm certain, as it's something that people frequently ask me about.  In the mean time, you can perform a 3-way merge as Carl mentioned to create a version of your file without the specific changeset in it.  Check out diffmerge.exe if you're looking to invoke our merge tool from the command line.  It's in your Visual Studio installation folder.
  
  Thanks,
  -Doug
  
  

• pchr

  - I could live without changeset rollback for now if I knew it was coming in the next version.
  
  - The diffmerge has some issues.  There are too many times I have to manually edit the "merged" window instead of just clicking on the changes in either of the two merge source windows.
  
  - I still can't say about item version numbers.  I am too colored by the fact that every VCS I've worked with used item version numbers.  I'm willing to try to think differently.  I'm just hoping there isn't some fundamental flaw in not having item version numbers that will bite us later.  In this regard, I'm trusting the TF team to make the right call here.
  
  - Shelvesets are cool but having "merge on unshelve" would fill a task gap that I think users will run into WRT to the "multiple users fix a single defect scenario".
  
  - I'm not sure exactly what the issues are with offline usage.  However, we have a lot of folks that develop on laptops and those laptops aren't always connected to the network.  If there are fundamental problems with this user scenario then that could be an impediment to adoption for us.
  

• Sailesh

  Thanks for the tip.  Add my vote to the list for wanting a "revert" feature to roll back at the very least the latest changeset.
  

• NeilMarshall444

  A blog entry would be great.
  
  I'm starting to get a sinking feeling though that VSTF SCC is "Cool, but unfinished", and worse that it may be years before it's finished due to the very long release cycles of VS itself.
  
  The question for myself and other customers to evaluate is whether the unfinished parts are important enough to be adoption blockers.  Is all the tight integration worth giving up a well-pollished SCC solution
  
  

• mthom

  Carl,
  
  Rolling back changesets was a cut we had to make.  Your comment is fair.
  
  I agree with you that the diff and merge tool in version 1 could definitely be better.  The good news is that you can plug in any diff and merge tools.  We've fixed the temp file name problem in the current code.
  
  I think it's likely that there will be a combo or other way to choose a workspace for the pending checkin tool window.  As you say, it's needed to deal with multiple-workspace scenarios.
  
  Merging shelved changes into a workspace was another cut.  Lots of folks internally want that as well.  While it won't be a part of the product in version 1, there's a chance you may see it as a separate tool. ;)
  
  I agree with your comments on offline support.  That's something we hope to improve on in version 2.
  
  As far as checking in an unmodified file, that will not create a new version of that file in RTM.  The checkout will simply be undone (unlike what you see in the beta).
  
  Interestingly, I think you did a pretty good job of pointing out things we had to cut.
  
  Thanks for taking the time to provide feedback.
  
  Buck
  
  

• Ooogaleee

  One nice side-effect of having "revert" on a changeset is that if the changeset updated many files, you can undo it all in one fell swoop.
  
  I wasn't able to come up with a procedure to simulate the missing 'revert' functionality other than by merging one file at a time.  Merging branches doesn't seem to correctly "un merge" changes when you specify a source revision that's older than the baseline of the branch.  But maybe I missed something.
  
  Performing the 3-way merge on a single file using diffmerge.exe is a nuisance because this tool can't deal with repository paths, so it's necessary to get all of the revisions you need into the filesystem before doing the merge.
  
  On the bright side, I can't recall ever needing to revert a large changeset that touched a bunch of files.  Just the same, the lack of this functionality feels like a big hole.
  
  

• Alexander Lowe

  Thanks. I knew about the MDI tab tooltip.  I was surprised at how quick I got confused about which version of the solution I was dealing with.  I think this has potential to really trip people up especially if there isn't an easy way to rollback unintended changes.
  

• Lawrence To The RESCUE

  Brian and Buck -
  
  Thanks for the feedback on the feedback :)   I hear ya on it being V1 - and we all know there ain't no V2 unless you get V1 shipped.  If some of the "V2" features could get rolled out before Orcas, that would be great.
  
  Despite my whining (it's my job ;-) I must add that overall I'm quite impressed with Team System - the integration is awesome.
  
  
  
  

• roadmaster

  I'd like to second Buck's compliment.  You've definitely picked out some of the most painful cuts we had to make.  I believe some of them will be addressed with web releases of utilities but some need core code enhancements.  Given that this is a V1 release, right now we are looking at ways to release a 1.1 kind of release on a shorter cycle than the "typical" VS release cycle.  We'll keep everyone posted as we make progress on figuring this out.
  
  Brian
  

• Juan.Faustino

  Some that I've noticed:
  
  - The lack of chageset rollback is a big one.
  
  - The diffmerge tool is weak - specifically in that it doesn't understand repository paths.  This makes it hard to use (since all files must be in the filesystem), and also hard to interpret (when you diff two respository revisions, the diff tool shows the garbage names of two temp files - you're left to figure out which is which).
  
  - The lack of per-item checkin comments.
  
  - I don't agree with the decision to eliminate item version numbers, but I could live with that.
  
  - The pending checkins window is as weak as it's ever been.  Getting a drop-down in there to show pending changes from other workspaces would be a great addition.
  
  - I'm put off by the fact that there is no stand-alone GUI for SCC.  I've always found the SCC integration in VS to be weak (barely usable would be more like it).  Having the TFC being nothing but a gutted version of VS doesn't really roll my socks up.
  
  - The lack of "merge on unshelve" is unfortunate.  The whole shelveset concept is great, but the lack of such an obviously useful feature makes it seem rushed.
  
  - The lack of a realistic ability to work offline is a big problem.  The "work arounds" that have been described are onerous and error prone.
  
  - In general, it seems to be lacking attention to little scenarios that come up frequently (while doing a fine job with the big scenarios).  For example, automatically dealing with check-in of an unmodified file in a way that requires no user interaction and doesn't pollute the files history with null changes.
  
  I'm still just getting started exploring this stuff part time, so maybe there's more that I haven't found (or maybe I've found all of my pain points already - who knows!)
  
  FWIW, the features that are there are rock solid, from what little testing I've been able to do.  In the end, I'll take rock solid and feature poor over unstable and feature rich.  Unfortunately for VSTF, I don't have to make that choice since there are any number of other SCC systems that already offer both.
  
  
  

• Russ05

  As Doug states, the feature was cut.  You can get limited automation of this using get, view, and resolve to back out edits to files.  I plan to write a blog post about it at some point.
  
  Buck

  
  
  
• Undoing a changeset?