Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
Thanks to everyone for some very interesting points. I am particularly intrigued by Stuart's handling of dictionaries using triggers. One particular challenge I may face is one particular hashed file (not a dictionary) which contains 2 1/2 million records that are under source control today. Copying them out to a directory might pose some problems with inode consumption. Perry -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Boydell, Stuart Sent: Friday, August 19, 2011 11:10 PM To: U2 Users List Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control 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
Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
What source are you keeping that has 2.5 million records -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Wednesday, 24 August 2011 01:39 To: U2 Users List Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control Thanks to everyone for some very interesting points. I am particularly intrigued by Stuart's handling of dictionaries using triggers. One particular challenge I may face is one particular hashed file (not a dictionary) which contains 2 1/2 million records that are under source control today. Copying them out to a directory might pose some problems with inode consumption. Perry ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
Not source but code lists which are updated at different intervals. Some examples: ZIP, CPT, ICD9, etc. - Original Message - From: Boydell, Stuart [mailto:stuart.boyd...@spotless.com.au] Sent: Tuesday, August 23, 2011 07:49 PM To: U2 Users List u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control What source are you keeping that has 2.5 million records -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Wednesday, 24 August 2011 01:39 To: U2 Users List Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control Thanks to everyone for some very interesting points. I am particularly intrigued by Stuart's handling of dictionaries using triggers. One particular challenge I may face is one particular hashed file (not a dictionary) which contains 2 1/2 million records that are under source control today. Copying them out to a directory might pose some problems with inode consumption. Perry ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users 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
Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
Hi Perry, I'd strongly suggest normal backup would be a better strategy for those items. Source Control is really designed for those things that you use to build a system. Code, parameters, schema (file dictionary) generation scripts, etc. The data for that system would typically *not* be kept in source control (unless you're feeling masochistic ;). Just in case you haven't seen this: http://tfsguide.codeplex.com/ has guidelines for what you want to do and which is TFS specific. Also, from what I just read, TFS is not case sensitive which will be an issue if you ever have 2 items under control with differently cased equivalent names. Payroll.Rpt PAYROLL.RPT -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Wednesday, 24 August 2011 10:50 To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control Not source but code lists which are updated at different intervals. Some examples: ZIP, CPT, ICD9, etc. - Original Message - From: Boydell, Stuart [mailto:stuart.boyd...@spotless.com.au] Sent: Tuesday, August 23, 2011 07:49 PM To: U2 Users List u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control What source are you keeping that has 2.5 million records -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Wednesday, 24 August 2011 01:39 To: U2 Users List Subject: Re: [U2] [UV] Microsoft Team Foundation Server for Source Control Thanks to everyone for some very interesting points. I am particularly intrigued by Stuart's handling of dictionaries using triggers. One particular challenge I may face is one particular hashed file (not a dictionary) which contains 2 1/2 million records that are under source control today. Copying them out to a directory might pose some problems with inode consumption. Perry ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users 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
Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
Source code control using TFS is not easily done. Microsoft created a command line client and a plugin for Eclipse. See http://www.microsoft.com/download/en/details.aspx?displaylang=enid=4240. However you want to accomplish this, you must create a script to copy the files to a local directory from TFS version control since it does not understand Universe file system. [ad] We have a client that has accomplished this using our Eclipse plug-in editor, called XLr8Editor. With the TFS plugin from Microsoft, this allowed them to copy the data files and dictionary files locally. From their local drive they can use another Eclipse plugin, called XLr8Installer. That plugin creates the files, copies the dictionaries, creates the indexes, copies the data, compiles the programs and catalogs the programs. Installations come out perfect every time and take just minutes versus the days we use to take to do it by hand with the copy command. [/ad] Regards, Doug www.u2logic.com The Eclipse plugin experts for U2 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
On 19/08/11 22:57, Doug Averch wrote: Source code control using TFS is not easily done. Microsoft created a command line client and a plugin for Eclipse. See http://www.microsoft.com/download/en/details.aspx?displaylang=enid=4240. However you want to accomplish this, you must create a script to copy the files to a local directory from TFS version control since it does not understand Universe file system. To which I would add - is TFS similar to sourcesafe, ie a centralised version control system? Having used sourcesafe, it's a ***ing nuisance if more than one programmer wants/needs to work on the same code at the same time. Look at using a DVCS such as git in addition to / instead of it. Even if you use TFS as your main source control, if programmers use git as their local source control they can write and test their work without needing to check out the central code. Then when they're ready, sync their local tree to the centre, checkout, one last QA run of their changes, checkin, and off they go again. That way, the central repository is only ever checked out for short intervals, and even if several programmers are working on the same code, they aren't trampling over each other's code. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Microsoft Team Foundation Server for Source Control
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
