Hi Perry, I use Perforce (P4) - similar (but different). Not sure what best practice is for TFS repositories is but with P4 and other Source Control (SC) systems something like the following should work.
//function/branch/path/item 1. Starting with a functional area - a project or a defined set of artefacts which make a up a particular system (eg Payroll) 2. branch - this is usually MAIN (eg the current, main or head version) - we occasionally have different branch versions for Australia & NZ or for a release branch. A commercial software developer would probably keep their major releases in different branches. 3. path - you should probably just start at the account directory. So if your complete path to the payroll account was: /usr/uvaccs/dev/perry/payroll/.. you would start at the *../payroll/..* level of the path and ignore the stuff before it. Not sure how TFS maps to the workspace, but I guess that you are able to give it a relative path like most SC systems. 4. The item under control. So you might end up with //Payroll/MAIN/PAYROLL/PAY.BP/PRINT.PAYSLIPS Also, not sure how TFS handles case sensitivity - this would be an issue if it regards Payslip & PAYSLIP as the same item. As far as hashed item go: convert everything you need to control to type 19 directory files (except dictionaries - see below). Why? Because you should only need to do this in dev. For all other environments the items should only be copied in (deployed) from a release file - so will be able to be plonked into hashed files by UV copy. If you can't convert them for some reason (like you have binary in them?!), you'll probably need to put a trigger onto your hashed files to manage the controlled items. Dictionaries - have to be hashed because otherwise I-types won't compile or work. So, I have a trigger for the dictionary that writes out the item to a type 19 file under source control. It truncates the I-type attributes after about att 10 so you don't get the binary in the repository. It also manages which SB+ items get put in and out of SC. If the item is not checked out from SC for edit before you try to edit the dictionary, the trigger will rollback the copy and gracefully tell you that you need to check out the item before editing it. On save it updates the type 19 copy after which it needs to be checked in. In my case I have 1 file set up for all the dictionary items. I use an assigned key and a lookup file to manage them. The thinking behind it was to reduce the number of folders to manage in SC. In practice it probably doesn't matter, if you have lots of dictionary folders or one folder with lots of items as we do. Release strategy. I use a program, but we also looked at "make" and the Perforce equivalent. These are nice because they can check dependencies - however, it was overkill for us so I just have a program that copies everything from a 'drop' location into the target system and compiles and runs any setup programs. Hope that helps, Stuart -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Saturday, 20 August 2011 00:57 To: U2-Users List Subject: [U2] [UV] Microsoft Team Foundation Server for Source Control Has anyone had any experience using Microsoft's Team Foundation Server for source control with UniVerse on a Linux server? I have the command line client functional and talking to the TFS server. I know I'll have to write some kind of interlude to manage those items in hashed files to get them out into the file system where they will be visible to the TFS client and to do the reverse upon checkout. What I'm looking for are some ideas for organizing in the TFS repository. Also, we're looking for a one-button deployment solution to be able to deploy our Windows/.NET software to the respective Windows servers along with the UniVerse software to the UniVerse server(s), run processes to create/delete files, index, etc. and compile and catalog BASIC programs. I know I'll probably have to build this "thing" to make this happen as I seriously doubt there is anything available off the shelf capable of doing this. Anyone been down this path? Thanks. Perry Taylor Zirmed, Inc. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
