Thanks Grant.
Solution 1: The trouble is we don't want the binary data to be replicated across immediately. The data is only compatible with the current code it was generated against. If one propagates the data across without its dependant code, the new data will either be corrupted or lost, or even worse destabilize the other teams. For this reason we merge content and code in the exact same operation. Solution 2: We already use this to enforce locking of files within a branch. However our problem is that the lock doesn't lock across all branches of that file. Check-in policy: Not really useful, because two users could work for a week on the same file but in different branches, and the second person to check their changes in will effectively have to throw their work away. So it really needs to be on Check-out Ive been though these options a few times, and I accept we will probably have to deal with this by writing some kind of client side tool or plugin that handles file locking/unlocking... unless someone has a cool idea that can solve it server side J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Holliday Sent: Wednesday, October 24, 2007 11:40 AM To: [email protected] Subject: RE: [OzTFS] Branched binary assets in TFS Hi Karl, >> Hi All, im new to this list; Ive got a burning question I want to throw out there: First of all, welcome - and that's what this list is for - questions like this. This is a common problem. There are two solutions that I can think of off the top of my head: 1. Use the "dependency replication" features of TFS Integrator 2. Setup "Source Control File Types" to lock particular file extensions exclusively 1: http://www.readify.net/tech+talk.aspx?TID=33&cid=10 gives an overview of how to set it up with dependency replication. What you would do is setup a dependency from MAIN to each of your branches. So when somebody changes something in the MAIN binary, it gets replicated to each of the branches. 2: The files that are configured to be locked via file type extension (in VS, Team -> Team Foundation Server Settings -> Source Control File Types) are locked exclusively. This is an all-or-nothing approach, you can't lock some files/paths, and not others. The other approach is of course a check-in policy like you suggested. Also look at Part II of the TFS guide: http://www.codeplex.com/TFSGuide. This might give you some ideas on how you might lay out your source control repository. Regards, Grant Holliday | Team System MVP <https://mvp.support.microsoft.com/profile/Grant.Holliday> Email: [EMAIL PROTECTED] | Blog: http://ozgrant.com <http://ozgrant.com/> | Mobile: +61 (0)402 414 446 ________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Karl Burdack (2K Australia) [EMAIL PROTECTED] Sent: Wednesday, 24 October 2007 10:44 AM To: [email protected] Subject: [OzTFS] Branched binary assets in TFS Hi All, im new to this list; Ive got a burning question I want to throw out there: Anyone have an idea how to manage binary assets across branches. When working in a simple main trunk, users just use locking to control this. However if you have one team on a branch, there doesn't appear to be a way to "lock across all branches" We have looked at implementing a check out policy, however it doesn't seem available, only check in policies are possible. Any ideas? Regards, Karl Burdack Technical Director 2K Australia OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com, supported by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com, supported by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com, supported by www.readify.net
