none
Private build - uanble to get workspace due to locked for checkout dll files

    Question

  • Greetings,

    We are in the midst of a large feature integration, and are utilzing shelvesets and private builds to work our way to a final commit.

    Our shelveset contains some updates to some 3rd party dll files, and we have found that if a developer does not undo his checkout after checking in a shelveset, we are unable to perform the private build.  The errors hit in the Get Workspace activity:

       The item $/Source/Apps/eFN/NetBin/ActiveReports.dll is locked for check-out by ENG01 in workspace ENG01.

    Checkouts of dll files cannot be unlocked (TF10152: ...dll must remain locked because its file type prevents mutliple check-outs) and it wouldn't be wise for us to change this in the file types editor, as doing so will affect the entire project collection.

    The only way we can successfully run the private build is to have the developer undo the checkout and wait for the build to finish before playing with the files again.

    Is there a way around this?  Nothing like this occurs with a standard build of the latest changeset if the same dll files are checked out by some user.

    What about the private build requires that it check out the files?

    Thanks much!

    -jdavid

    <dir><dir>

    </dir></dir>
    • Modifié jdavidi jeudi 22 mars 2012 21:22
    jeudi 22 mars 2012 20:18

Réponses

  • Hello jdavidi,

    As far as I know that TFS supports automatic lock behavior based on the file extension being checked out. Any time a pending change is made to an item, the file types list is checked to see if the extension requires automatic locking at checkout. And a lock cannot exist in a shelveset, so if you lock an item and try to shelve it, stripped as part of the shelve operation. However, automatic locks can cause trouble when unshelving pending changes, if you preserve the changes in your workspace by checking the "Preserve pending changes locally" checkbox when shelving them, any attempt to unshelve the shelveset will fail, since you still have the locks in your current workspace.

    So to deal with your issue, you should configure your TFS server do not automatic lock for .dll files. Right click the team project collection in the Team Explorer, select Team Project Collection Settings->Source Control File types->find the *.dll node click Edit... and check the box for "Enable file merging and multiple checkout." 

    Please refer to this blog for further information about TFS locks:

    http://blogs.msdn.com/b/phkelley/archive/2008/11/12/everything-you-ever-wanted-to-know-about-locks.aspx

    Thanks.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us

    • Marqué comme réponse jdavidi mardi 27 mars 2012 12:48
    lundi 26 mars 2012 09:56
    Modérateur

Toutes les réponses

  • Hello jdavidi,

    As far as I know that TFS supports automatic lock behavior based on the file extension being checked out. Any time a pending change is made to an item, the file types list is checked to see if the extension requires automatic locking at checkout. And a lock cannot exist in a shelveset, so if you lock an item and try to shelve it, stripped as part of the shelve operation. However, automatic locks can cause trouble when unshelving pending changes, if you preserve the changes in your workspace by checking the "Preserve pending changes locally" checkbox when shelving them, any attempt to unshelve the shelveset will fail, since you still have the locks in your current workspace.

    So to deal with your issue, you should configure your TFS server do not automatic lock for .dll files. Right click the team project collection in the Team Explorer, select Team Project Collection Settings->Source Control File types->find the *.dll node click Edit... and check the box for "Enable file merging and multiple checkout." 

    Please refer to this blog for further information about TFS locks:

    http://blogs.msdn.com/b/phkelley/archive/2008/11/12/everything-you-ever-wanted-to-know-about-locks.aspx

    Thanks.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us

    • Marqué comme réponse jdavidi mardi 27 mars 2012 12:48
    lundi 26 mars 2012 09:56
    Modérateur
  • Thanks for the confirmation, Vicky. 

    I'd initially had reservations around toggling that for the whole collection, but on the off chance that more than one person tries to affect the same 3rd party dll simultaneously, I can force them to go through with the merge exercise.

    mardi 27 mars 2012 12:48