locked
ETM: Team Project Collection Merge - preservation of IDs RRS feed

  • Question

  •  Issue:

    When merging one team project collection (TPC) into another:

    Page 9:

    ... current thinking is ... with the primary goal of preserving content.

    ...this means it would be acceptable to assign new numbers to work item IDs, changesets and any other entity that has an ID or name.

     

    Action:

    Is there a way of preserving externally referenced identifiers i.e. making the distinction between an external identifier and the primary key (PK) used in the DB? I'm wondering how acceptable it is for users to be concerned with issue 12345 one day then having to adjust to the ‘same’ issue becoming 45678 the next day after the TPCs are merged.

    Using this as an example, we could have an external identifier that is 12345.ABC, where ABC is an alphanumeric ident associated with a particular TPC. When the item is moved, it becomes 12345.CDE, where CDE is the ident of the new TPC. The “12345” being a prefix acts as visual continuity for the user so they recognise it as being the same item.

     

    Although TFS is an integrated system there are bound to be other systems / manual processes hanging off it that record item IDs. Managing to preserve them would be very useful.

     

    Friday, June 27, 2008 10:29 AM

All replies

  • Hello Mic,

    I have asked our ETM expert -and author of the spec to get back to you and the forum.
    Thanks
    Chuck
    -Chuck
    Friday, April 10, 2009 9:00 PM
  • Hi Mic,

    First let me thank you for taking the time to read the spec and provide us with your feedback. You are correct that internally we can store the work item as a "guid" and hence there is no real collision during merges, but the problem as you outlined is in the display name of that work item.  At the end a work item must have a url and a unique reference for the user and in the case of merge unfortunately there is the possibility of having ambiguity in the name (e.g. 12345).

    In the proposal you described I think there is still a possibility of a collision since 12345.tpc2 can exist in the current team project collection. When you merge 12345.tpc1 into tpc2 the change will cause a collision and in that scenario one of the artifacts must change name.

    Thoughts?

    -- mario


    TFS Program Manager
    Sunday, April 12, 2009 7:58 PM