locked
Source Control doesn't do an automatic get latest on checkout?! RRS feed

  • Question

  • We've been using the new source control for about a month now, and it seems everytime somebody goes to check-in there code there are all kinds of issues with stuff being out-of-synch.  And it seems the code on the source control server never seems to compile, but of course the local copy of everybodies machines do.  I've been pulling my hair out trying to figure out why everything keeps getting out of synch...today I found out why.

    It seems that in the new source control when you start editing a file it automatically does a check-out for you, but it doesn't do a get latest version on it.  So if somebody has made a change to the file since the last time you did a get latest on it, you will be modifying an old version of the file.  Even SourceSafe would do get the latest version when you did a Checkout...

    Is there any way to change this behaviour?!  This is a BIG deal, even if we tell people they have to do a manual get latest before they start editing, I know people will forget sometimes.  Then come check-in time they will have big problems.

    Tuesday, January 10, 2006 10:36 PM

Answers

  • I just noticed the other recent post about this behaviour.  Feel free to delete this post, I have my answer - there is currently no way to enforce this.

    I think not including this functionality is a huge misstep on MS's part though.  I can foresee this causing a tonne of problems for most dev shops out there.  I can't imagine how MS employees have managed to dogfood this for so long without having a tonne of issues due to this.  Out in the rest of the world I think the issues will be magnified even more because people are so used to sourcesafe and just take this behaviour for granted (my .02).

    Wednesday, January 11, 2006 12:16 AM

All replies

  • I just noticed the other recent post about this behaviour.  Feel free to delete this post, I have my answer - there is currently no way to enforce this.

    I think not including this functionality is a huge misstep on MS's part though.  I can foresee this causing a tonne of problems for most dev shops out there.  I can't imagine how MS employees have managed to dogfood this for so long without having a tonne of issues due to this.  Out in the rest of the world I think the issues will be magnified even more because people are so used to sourcesafe and just take this behaviour for granted (my .02).

    Wednesday, January 11, 2006 12:16 AM
  • Ooops, what is the other post about that subject? That really freaked me out! If this behavior is for real, I'll tell my team to run away from TFS SC! I have nightmares just imagining the mess that would cause...

     

    Regards,

    Max Andrade

    Wednesday, January 11, 2006 3:51 PM
  • Max -- this design has been discussed a few times.  See here for instance: http://blogs.msdn.com/buckh/archive/2005/08/20/454140.aspx

    Once you actually try the product, I imagine you won't find it nearly as limiting as it must seem just from reading these descriptions + your current mental model.  Having to perform a content merge during checkin every now & then isn't optimal, sure, but hopefully after some real-world usage you'll come to see why the VSS way is even more limiting.

    I can't imagine how MS employees have managed to dogfood this for so long without having a tonne of issues due to this. 

    I doubt I've spent more than a few minutes reviewing content merges during the entire product cycle.*  OTOH, if we couldn't guarantee that the set of files in our workspace was buildable, we'd never get anything done -- we rely on build scripts pretty heavily.  Same goes for the alternative: in order to preserve that invariant, I suppose we could make it so that every checkout sunc your workspace, but even with the proxy server our machines would spend more time talking to Redmond than doing something useful.

    Different teams use source control in different ways, of course.  YMMV, and probably will -- rest assured we'll be listening to your feedback when it comes to designing v2.  Personally, when I go home from a day of hammering on complex TFS corner cases and play with simple projects using CVS, it's the latter that annoys me more ;)

    *on production dogfood, that is.  My job description includes lots of testing around these scenarios, of course.

    Wednesday, January 11, 2006 6:18 PM
  • Richard,

     

    I read all related stuff now, but I’m still afraid about it. This change is too deep… What bothers me more is the idea that now we share more responsibility about code consistency with our team. Analyze conflicts and make merge decisions were tasks that we always tried to keep far from our regular developers. It seems now that it will become a usual task :(

     

    I really think a change like that should come with major warnings around it. If people start using this new source control system unwarned, they will probably get into problems, blame the tool, and create a bad fame around it (what can become difficult to fight against in the future).

     

    Ok, I’ll listen to your advice and run major tests (now with this behavior clear in my mind). Let’s see what happens. Anyway, in my opinion, this tool would not go RTM before the implementation of “automatic get latest during check-out” option, this is a must have.

     

    Regards,

    Max Andrade

    Wednesday, January 11, 2006 7:57 PM
  • Max,

    I totally agree... We couldn't believe it ourselves when one of the developers thought he was making changes to the latest version of some of the code files and suddenly after checkin everything went wrong. This new behaviour should have been an option and not a default. The fact that the merge screen doesn't show any labels on the buttons doesn't help whatsoever...

    Regards,
    Peter Bauwens
    Wednesday, January 11, 2006 9:38 PM
  • I understand (now) the model you are trying to move towards.  I think that in order to employ the new model though you have to have developers that are empowered to make merge decisions at check-in time.

    I run the dev department at a mfg company.  We have a mix of senior and junior developers here.  For the senior dev's I would have no problem empowering them to make merge decisions at check-in and we could resolve the issues that way.  However, I am not comfortable giving our junior devs that responsibility.  They may not understand the impact of the decisions they make while merging files.  That is one of the reasons why we have shared checkout on the code files turned off here.

    Like I said before, I don't think my scenario is unique, in fact I imagine it is quite common (although probably not so internally at MS).  Perhaps this is something that could be considered for addition to the powertoys suite, some kind of add-in that would allow us to turn on the behaviour of doing a get latest on checkout.

    Thursday, January 12, 2006 12:10 AM
  • To be clear, the only time someone would be prompted to manually merge is when:

    (1) multiple checkout is enabled (you indicated you turn this off?), AND
    (2) two developers modify the same block of code

    I definitely agree that merging decisions should only be made by people who are very experienced with the codebase.  But an even stronger best practice is for everyone to avoid part 2 -- work item tracking should be able to help in that regard.

    "Get latest on checkout" (i.e., only part of a changeset is sunc) can never be the default due to the way it breaks build integrity, but rest assured enough people have asked for it that scenarios like yours will weigh heavily in v2 design decisions.

    Thursday, January 12, 2006 12:29 AM
  • Richard (and Buck if your reading), to add a little bit more feedback for you on my situation.  The model we are using at my company is to split up the tasks between code files, so no two developers have to have the same code file checked out at the same time.  This allows us to turn off the shared checkout option, and it makes the learning curve easier for our devs.

    Lets say developer Dan makes some changes to our codebase, perhaps he changes the name of some web service method and then modifies some UI forms that call it to match.  Then he checks in all his code, all is well.

    Later, developer Joe has some changes to make to the same form.  He checks out the form he needs but forgets to do a Get Latest.  When checkin time for Joe rolls around we have a problem.  His code uses the old method name for the web service, but if he checks that in the codebase in our source control will no longer be compilable because the UI code and the web service code will be out of synch.  We wish to avoid merging, but even if that wasn't a concern I don't believe this scenario could be easily solved by merging because its not a matter of just selectively keeping portions of the server copy and local copy, because perhaps the code sections that call this method have been modified by Joe, so if in the merge tool you choose to use the server copy of that section (with the updated method name) you will be losing the changes that Joe made.

    If only VS had done an automatic Get Latest on checkout this problem would never arise.  Not only that, but I believe that if you have shared checkout turned off, AND have it do automatic Get Latest on checkout, a developer should NEVER be presented with a merge dialog.  That is what I want, no merge dialogs ever.

    It seems like the new source control model has a tonne of flexibility to support extremely complex codebase scenarios, but it lacks the ability to easily support simple scenarios.

    Thursday, January 12, 2006 12:40 AM
  • Yeah, that's exactly my point of view!

    Thursday, January 12, 2006 12:49 AM
  • I also want to say, that my point of view is the same. In our project, this strategy also cause some problems. I think it should be optional at TFS server(or better at client) to get latest version before checkout. I think it is not a problem.
    Thursday, January 12, 2006 5:47 AM
  • Is "Check Out for Edit" behavior different depending upon multiple users vis-a-vis multiple workspaces?

    For example, I modify a file in Workspace_1, check it in, and then switch to Workspace_2 (both workspaces are in my local machine and have the same file mapped).

    If I do "Check out for Edit" in Workspace_2, SCE shows a dialog box asking me whether I want to open Server version or Local version of the file. Doing a "Get Latest Version" also retrives the latest version (with changes checked-in from Workspace_1).

    Does the system behave differently if changes are checked-in by another user as opposed to from another workspace? Why should the two scenarios be different? Seems like SCE has the ability to figure out whether the current workspace contains the latest server version of the file or not ? I am using Beta3 refresh.

    Thanks in advance for clarifying.

    Saturday, January 14, 2006 8:25 PM