Re: [U2] Version Control
Regarding your snippets below: Would this really be something you want? Your ongoing work merged into everyone else's ongoing work every day - before your work is finished and tested? I approached the whole concept of items being checked out to others differently - you can take a branch copy, but the idea of a branch copy is that it branches from the root - the live version, I guess. Each person can work on their branch, but one gets tested and goes live separately from the other - unless you choose to combine the projects. Also went down the road of automatically merging work in a program done by two different people for two different reasons. It can be fraught with error - at least in my experience. It needs human eyes to decide what goes where! Depending on the complexity of the changes, I guess. We overcame the problem of someone coming along later with a higher priority project by allowing the branches to be swapped out, so the first programmer does not have to check-in/lose their work. Lots of ways to skin this cat, I have learned over the years. Susan Message: 15 Date: Fri, 04 Mar 2011 10:42:58 + From: Wols Lists antli...@youngman.org.uk And the nice thing is, every time you change branch, or every morning or whatever, you can do a pull; merge and you're development copy keeps in sync with all the changes every one else is making. But I would say, even if no-one else in your organisation is using it, it's a damn good tool for you to use for your own work. If you've got several people working on a centralised VCS, I've had enough pain where we've been tripping over each other trying to update the same file. You can have a master branch tracking the central system, then do your own development in your own branches. When you need to commit, sync your master with central, check out central, merge your changes into your master, then commit back to central. That way, you're not held up because you can't check out a file, and you're not swearing when you're half way through make a LOT of not-so-important changes, and someone comes along saying you need to check that back in, I've got an emergency to fix!. I'd say play with git! It's a nice system, and there's absolutely no need whatsoever for it to impact on anybody else around you, unless you want it to. And other people will probably start using it too, once you realise how nice and powerful it is. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
On 05/03/11 11:53, Susan Joslyn wrote: Regarding your snippets below: Would this really be something you want? Your ongoing work merged into everyone else's ongoing work every day - before your work is finished and tested? Sorry, but I have to respond here ... NO NO NO. Not my work merged into everyone else's, but the master tested copy merged into mine! I keep my tree in sync with the master version, I totally agree you shouldn't keep syncing your untested work into the master tree! Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
On 03/05/2011 06:53 AM, Susan Joslyn wrote: Regarding your snippets below: Would this really be something you want? Your ongoing work merged into everyone else's ongoing work every day - before your work is finished and tested? I think the idea is you move discrete, completed patches to the main location. If 2 people apply patches to completed separate areas of the same code, there should be caution, but I wouldnt call everything to a halt because I have the src right now. At this point I think communication occurs to make sure all parties are aware of each other. If 2 people apply patches to the same lines, that is a more serious condition. testing needs to occur repeatability as the parties reconcile their projects. The code reservation I think is an older paradigm. Nowadays, projects work in parallel, and a responsible party is watching the stream of patches. Every dev is aware that they are not working in a vacuum. For the end-user, I think they are happier and better served because projects can occur in parallel and delivery _can_ occur faster. I know I have said many times in my shop, We are waiting on project X to finish because they have resources we need. Some of the tools have specific features to handle particular workflows. They are not all equal and the chore is picking the correct one for your organization. This is just my opinion here. Please set me right if I am off base. Git- I personally think git is best for very large workgroups working on a single large codebase (i.e. an os kernel). It is primarily geared to people comfortable in the shell. It does _not_ have good win32 support so it is a non-starter for me. Subversion - Very popular, but declining. The leader in the centralized repo group. It replaced cvs as the defacto standard for the 90's and 2000's. There is only one copy of the repo and to record _any_ change you must make a network connection. A shortcoming I see is if this repo is damaged, all of your resources are in one place. Google subversion merge hell and see how many hits you get. Subversion also suffers from speed problems with large repo's. All three major dvcs's (git, bazaar (bzr), and mercurial (hg)) were designed to combat all 3 of these problems. DVCS's are much faster. Here are some benchmarks. https://git.wiki.kernel.org/index.php/GitBenchmarks#bzr.2C_git.2C_and_hg_performance_on_the_Linux_tree DVCS's are much safer. Here are some links. http://stackoverflow.com/questions/4592740/mercurial-compared-to-private-branches-in-svn/4594085#4594085 http://stackoverflow.com/q/2518779 This one is interesting because he includes massive numbers of binary files, i.e. jpegs and word docs. Not that svnquickly gets to the 20 minute range where all 3 dvcs's are in the 1-2 minute range for the same activity. I have a least one workflow that requires good performance on binary files (optio dcl files). http://joshcarter.com/productivity/svn_hg_git_for_home_directory For safety, if anything happens to any of the dvcs local dev repo's all they have lost are changes they have not pushed upstream. Learning to operate in a my repo, your repo, master repo environemnt, me and devB are aware of each others work, I am pulling her new changes into my repo. We basically have a 3 way backup going on. If you count the repo on my laptop, there is a 4th backup. If there is a massive fire at hq and the server and both devs machines are smoldering heaps, my laptop repo may contain 99% of all the src. Since it is not a main machine, I likely and not pulling changes as frequently. Bazaar is very similar to git and hg. It seems to be primarily tied to Canonical LLC's projects and not a lot of activity outside of that world. I used it for a short time but found hg to meet my needs better. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
On 05/03/11 09:30, Steve Romanow wrote: Git- I personally think git is best for very large workgroups working on a single large codebase (i.e. an os kernel). It is primarily geared to people comfortable in the shell. It does _not_ have good win32 support so it is a non-starter for me. Mmmm. I take your point about it being a cli program, not a gui. But why is it best for large workgroups? True, it makes merging stuff into a single central repository easy, but most of its features are aimed at the lone developer. It's just that they're the same features that are needed by a group. If you're trying to work on several things at once, it makes your life easy. Where's the difference between one developer multi-tasking, and multiple developers co-operating? Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
On 03/05/2011 03:29 PM, Wols Lists wrote: On 05/03/11 09:30, Steve Romanow wrote: Git- I personally think git is best for very large workgroups working on a single large codebase (i.e. an os kernel). It is primarily geared to people comfortable in the shell. It does _not_ have good win32 support so it is a non-starter for me. Mmmm. I take your point about it being a cli program, not a gui. But why is it best for large workgroups? True, it makes merging stuff into a single central repository easy, but most of its features are aimed at the lone developer. It's just that they're the same features that are needed by a group. If you're trying to work on several things at once, it makes your life easy. Where's the difference between one developer multi-tasking, and multiple developers co-operating? Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I stand corrected. I have not used git so I should prob reserve any judgement. I guess the only thing I have experienced with it is it seems more complicated than both hg and bzr. I like the single hg command with many subcommands and the plugin structure of bzr and hg. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
I completely and enthusiastically agree that the time for parallel development has arrived! There are many ways to approach that challenge. We've tried a few - and I've looked at a lot of tools that have different approaches in different environments. When you are dealing with a development environment where the concept of a build is truly relevant - where you are taking a snapshot of the program and its whole working environment, it works to let everyone take to their own sandbox and re-check-in/merge in whatever order the work is completed. In our environment this poses certain additional challenges. It is difficult to predict what components will constitute the build for any particular program in a U2 environment - even more so when SB+ or other dictionary-driven ADEs are used. Our compromise is to 'branch' the individual components in the order that they are taken. If a branched item needs to promote before the others a step must be taken to swap out the priority so that then this branch of this program is tested in the environment and delivered with whatever goes along with it. In an environment where coding is done in single, discrete procedural programs it might work to go with a sandbox and isolated testing. Our approach to branching is test-driven. What I mean by that is how the software will be tested is the driving force. Accommodating a realistic test bed. Some folks try on the concept of many different dev areas - like sandboxes but full working copies of the production software. This provides a platform for testing the overall functionality of a completed project, but then once that software is moved in to where other changes may have occurred - not just to the program in question but to anything around it - it all has to be tested again, anyway. Which one of the various approaches will work best depends upon the way the software is designed, the personalities and productivity of the programmers, the sheer volume of change and - the great flattener - whether there are really testers/testing going on. The quality and control at that level. Over the years, PRC has been taught to accommodate many approaches. We've found that it practical use, some seem to work better than others. Short of isolating a product to one solitary developer, there are not perfect answers - well, not that I have been able to discover, yet! I'm fascinated to hear anyone else's ideas and experiences. Susan -Original Message- From: Steve Romanow [mailto:slestak...@gmail.com] Sent: Saturday, March 05, 2011 8:30 PM To: sjos...@sjplus.com; U2 Users List Subject: Re: [U2] Version Control On 03/05/2011 06:53 AM, Susan Joslyn wrote: Regarding your snippets below: Would this really be something you want? Your ongoing work merged into everyone else's ongoing work every day - before your work is finished and tested? I think the idea is you move discrete, completed patches to the main location. If 2 people apply patches to completed separate areas of the same code, there should be caution, but I wouldnt call everything to a halt because I have the src right now. At this point I think communication occurs to make sure all parties are aware of each other. If 2 people apply patches to the same lines, that is a more serious condition. testing needs to occur repeatability as the parties reconcile their projects. The code reservation I think is an older paradigm. Nowadays, projects work in parallel, and a responsible party is watching the stream of patches. Every dev is aware that they are not working in a vacuum. For the end-user, I think they are happier and better served because projects can occur in parallel and delivery _can_ occur faster. I know I have said many times in my shop, We are waiting on project X to finish because they have resources we need. Some of the tools have specific features to handle particular workflows. They are not all equal and the chore is picking the correct one for your organization. This is just my opinion here. Please set me right if I am off base. Git- I personally think git is best for very large workgroups working on a single large codebase (i.e. an os kernel). It is primarily geared to people comfortable in the shell. It does _not_ have good win32 support so it is a non-starter for me. Subversion - Very popular, but declining. The leader in the centralized repo group. It replaced cvs as the defacto standard for the 90's and 2000's. There is only one copy of the repo and to record _any_ change you must make a network connection. A shortcoming I see is if this repo is damaged, all of your resources are in one place. Google subversion merge hell and see how many hits you get. Subversion also suffers from speed problems with large repo's. All three major dvcs's (git, bazaar (bzr), and mercurial (hg)) were designed to combat all 3 of these problems. DVCS's are much faster. Here are some benchmarks. https://git.wiki.kernel.org
Re: [U2] Version Control
This would be easy for me to implement - thinking out loud, though, I don't think I have any customers who promote to live that frequently. But I suppose it could poll live each morning and make the suggestion. Any of my (PRC) customers who see this and are intrigued by this, pipe in or email me off line. And the nice thing is, every time you change branch, or every morning or whatever, you can do a pull; merge and you're development copy keeps in sync with all the changes every one else is making. SJ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
On 04/03/11 00:55, Bill Brutzman wrote: It is not clear to me how SubVersion and GIT developers refer to the latest rev of their subs. Also the reverse...what programs use the subs. This is where OSGI fits in. I have heard rumblings that people are working on an Eclipse-compatible OSGI SCM thing. OSGI is worth learning about. OSGI is a configuration tool that grew up out of the cell phone industry to handle config control on say, a Nokia family of products. Git, certainly, you have two techniques. The commit ID for any given file(s), and the tag or branch for any given application. Application in quotes because it can refer to as much or as little of your system as you want. I'm currently playing with / learning git. The whole point of a DVCS is that there is NO master copy, other than by convention. So each developer is likely to have their own development account, and then there's the central development account. Where git really scores (dunno about other systems) is the ability to switch between different problems very quickly and easily. You could have a long-term project you're working on, and a medium term development job. It's dead easy to switch between the two - commit a; checkout b and you've just changed from one to t'other. Then someone might come to you with drop everything - we've got a problem on live so stash; checkout new branch from live and you're running on a copy of live, in a new branch, where you can modify and test things. Once it's all working, commit; push to live system (or pull from live system) and the fix has gone live. drop copy of live; checkout development; and you're back where you started. And the nice thing is, every time you change branch, or every morning or whatever, you can do a pull; merge and you're development copy keeps in sync with all the changes every one else is making. And these commands probably take longer to type than to run :-) But I would say, even if no-one else in your organisation is using it, it's a damn good tool for you to use for your own work. If you've got several people working on a centralised VCS, I've had enough pain where we've been tripping over each other trying to update the same file. You can have a master branch tracking the central system, then do your own development in your own branches. When you need to commit, sync your master with central, check out central, merge your changes into your master, then commit back to central. That way, you're not held up because you can't check out a file, and you're not swearing when you're half way through make a LOT of not-so-important changes, and someone comes along saying you need to check that back in, I've got an emergency to fix!. I'd say play with git! It's a nice system, and there's absolutely no need whatsoever for it to impact on anybody else around you, unless you want it to. And other people will probably start using it too, once you realise how nice and powerful it is. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
When fixing THIS.APP, copy all the source code from THIS.APP.R3 to THIS.APP.R4, complile .R4, test .R4 in a SandBox, change VOC in LIVE from R3 to R4. ED VOC THIS.APP 1: PA 2: RUN BP.INV THIS.APP.R3 --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David Sent: Friday, March 04, 2011 1:59 AM To: 'U2 Users List' Subject: Re: [U2] Version Control If you are using U2 environment a lot of stuff won't work without utilising the VOC some fundamental or critical way. VOC entries for files, programs, paragraphs/PROCS, etc. Granted, in some cases these don't change often. Unless you are like some poor sites I have seen and run their entire or parts of their application process from a paragraph or proc in the VOC file - more common than you would like to think or hope! Likewise, control information inside U2 files are in many case extremely critical for many applications - this also needs to be managed and versioned, rolled-back if required, etc., etc. Any configuration management application needs to take everything into account not just source code. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Sent: Friday, 4 March 2011 1:48 PM To: 'U2 Users List' Subject: Re: [U2] Version Control Hi Bill: The U2 world works inside the database. The rest of the world thinks source code control should be outside the database. Your use of VOC is very unique and probably applicable to a small set of the U2 community. Source code control, except for U2, is done from the local workstation and not on the server. ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ** ___ 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] Version Control
One year ago, I was editing all of my code with EditPlus, an FTP editor. From an editing perspective, the source code was a file in a folder on a Unix box, the same Unix box that was running UniVerse. Inside UniVerse, there was a file pointer (in VOC) to the source and object code. One of the selling points of SubVersion (and others) is that a programmer could write code on a plane and then re-sync once the plane lands. As a lone ranger, checking code in and out has little meaning. Graphic 1: How does VOC knows what is the LIVE rev?. Is U2Logic's Version Control included with the XLr8 editor? --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Sent: Thursday, March 03, 2011 9:48 PM To: 'U2 Users List' Subject: Re: [U2] Version Control Hi Bill: The U2 world works inside the database. The rest of the world thinks source code control should be outside the database. Your use of VOC is very unique and probably applicable to a small set of the U2 community. Source code control, except for U2, is done from the local workstation and not on the server. When I was a Configuration Manager for a telecom software company, many moons ago, we did not store any changes inside either the Informix or Sybase databases. We stored all of source code revisions on several Unix boxes that the programmers had to check out and check in from their workstations. I have created a web page that shows how Eclipse maintains a local version. There is a graphic of what U2 project looks like as well as few more. You need to look at the last graphic. That is where version control shines and shows you what you checked in and why. The pretty pictures of Eclipse version control using the XLr8Editor plug-ins is feature here and you can click on any of images to enlarge them: http://www.u2logic.com/versioncontrol.html. Regards, Doug www.u2logic.com Universe and Unidata Eclipse based tool supplier ___ 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] Version Control
Bill: You are editing locally: that is how Eclipse works. You must copy from the database or version control to edit the programs in this case. Unidata and Universe do not have an external BASIC compiler. We must compile within the U2 database. We have created tools in Eclipse to copy all or a single program from the U2 database to your workstation. You then edit your program on your work station. When you want to compile it, we send the program back the place we got it from and compile it on the database server. All version control packages in Eclipse copy those programs locally as well, where you can then edit them. When creating a project you point to the Test or Live Account you want to edit the source from. When you are done editing, Eclipse will copy it back into that account. If you are happy with the results after testing, you can Team it in to your version control with notes on what got changed. That is all you have to do. No editor wrappers, no scripts for Windows or Unix, no changes to your Universe or Unidata database, no external or internal programs to worry about, no accounts to load, no software to install on your database server. XLr8Editor uses Version control from what every plug-in you have on Eclipse. Be it Subversion, CVS, GIT, or Perforce, you pick what version control you want. Where the version control software lives is your choice as well. Regards, Doug www.u2logic.com/tools.html XLr8Editor for Universe or Unidata still $49.00 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: Friday, March 04, 2011 9:04 AM To: U2 Users List Subject: Re: [U2] Version Control One year ago, I was editing all of my code with EditPlus, an FTP editor. From an editing perspective, the source code was a file in a folder on a Unix box, the same Unix box that was running UniVerse. Inside UniVerse, there was a file pointer (in VOC) to the source and object code. One of the selling points of SubVersion (and others) is that a programmer could write code on a plane and then re-sync once the plane lands. As a lone ranger, checking code in and out has little meaning. Graphic 1: How does VOC knows what is the LIVE rev?. Is U2Logic's Version Control included with the XLr8 editor? --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
Hi Bill: I find this very messy. After a program has been changed 50 times, do I really care what the other 49 versions look like in my U2 account. I think not. I sometimes change a program every 1 to 5 minutes as I'm going through testing process. Then sometimes about an hour into it I think, wow I would like to have the version from 30 minutes ago which worked better than the current version. With Eclipse there is a local history and I save the last 100 copies, so I use the local compare editor to find the version I would like to go back to. You can change this preference to fit your needs. Eclipse makes me more productive. I can work on multiple accounts within the same window using tabs. I feel that my code is cleaner because of the Outline capability of all my variables in the program, the ability to double click and see where the variable is used. Other things like the way Eclipse ruler show me visually where all those variables are so I can check my scope has made my code less problematic when it comes to unassigned variables at run time. Regards, Doug www.u2logic.com/versioncontrol.html The Eclipse U2 Experts -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: Friday, March 04, 2011 8:32 AM To: U2 Users List Subject: Re: [U2] Version Control When fixing THIS.APP, copy all the source code from THIS.APP.R3 to THIS.APP.R4, complile .R4, test .R4 in a SandBox, change VOC in LIVE from R3 to R4. ED VOC THIS.APP 1: PA 2: RUN BP.INV THIS.APP.R3 --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
On 3/4/2011 11:59 AM, Doug wrote: Hi Bill: I find this very messy. After a program has been changed 50 times, do I really care what the other 49 versions look like in my U2 account. I think not. I sometimes change a program every 1 to 5 minutes as I'm going through testing process. Then sometimes about an hour into it I think, wow I would like to have the version from 30 minutes ago which worked better than the current version. With Eclipse there is a local history and I save the last 100 copies, so I use the local compare editor to find the version I would like to go back to. You can change this preference to fit your needs. Eclipse makes me more productive. I can work on multiple accounts within the same window using tabs. I feel that my code is cleaner because of the Outline capability of all my variables in the program, the ability to double click and see where the variable is used. Other things like the way Eclipse ruler show me visually where all those variables are so I can check my scope has made my code less problematic when it comes to unassigned variables at run time. Code annotation is nice too, where you can view code and see the changeset that introduced the change (all in one view) in the browser or Tortoise. Anyone who has cloned your repo has this exact same visibility for blame support. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
David, I agree! This is my main argument for driving the sdlc / change control from within U2. ( And of course my product, PRC. ) Plus you can control all kinds of outside stuff - talking back and forth to other products - from within U2. Those other applications cannot 'drive' the change control for the rest of the things inside U2 besides basic programs in directories. Plus a separate solution for data integrity is still required. Susan Message: 13 Date: Fri, 4 Mar 2011 17:59:11 +1100 From: Hona, David david.h...@cba.com.au To: 'U2 Users List' u2-users@listserver.u2ug.org Subject: Re: [U2] Version Control Message-ID: 297b19fd90fdb14da1c8ceff0b6cffe76a3fee8...@vaunsw139.au.cbainet.com Content-Type: text/plain; charset=us-ascii If you are using U2 environment a lot of stuff won't work without utilising the VOC some fundamental or critical way. VOC entries for files, programs, paragraphs/PROCS, etc. Granted, in some cases these don't change often. Unless you are like some poor sites I have seen and run their entire or parts of their application process from a paragraph or proc in the VOC file - more common than you would like to think or hope! Likewise, control information inside U2 files are in many case extremely critical for many applications - this also needs to be managed and versioned, rolled-back if required, etc., etc. Any configuration management application needs to take everything into account not just source code. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
Doug: I have been considering this matter for some time... It seems that software development in the non-U2 world revolves around huge Maven scripts to re-compile builds of vast dynasties of code. The U2 VOC concept makes all of this hassle go away. With VOC, we just update the single program that I am working on with a new Rev.ID. Menus and other programs just launch what is in VOC. The program's rev is specified in VOC. The calling program just references VOC... the latest revision is specified in VOC. Thus, this scheme is modular. It is not clear to me how SubVersion and GIT developers refer to the latest rev of their subs. Also the reverse...what programs use the subs. This is where OSGI fits in. I have heard rumblings that people are working on an Eclipse-compatible OSGI SCM thing. OSGI is worth learning about. OSGI is a configuration tool that grew up out of the cell phone industry to handle config control on say, a Nokia family of products. A MultiValue database for rev control makes a lot of sense. 1)While this scheme is editor independent, Eclipse has some nice functionality that could be leveraged. 2) While this scheme is intended for code, it works the same way for procs, paragraphs, and dictionaries. 3) The updates are on a program-by-program basis, that is, NOT batch. 4) The updates are known to be applied because the screen that shows all of the revs, also shows what is in VOC right then. If the new program has a bug, it is easy just to roll back to the prior rev in VOC. ChChanges To SHS ___ B.HOP SHIP.STOCK.R91 __Path__ B.HOP Voc: R91 __#___Rev___Summary___Subs__Who___When__ 57 R91 CountDown 1 SUB.COUNTDOWN.R1 24 FEB 11 56 R89 Deleted [D]eliveries 16 FEB 11 55 R86 UpDated PackSlip, Cert RR08 FEB 11 54 R85 Fixed Ship.To.Country 07 FEB 11 53 R81 Fixed Bug, No UPS Acct If UPS Freight Karen 16 NOV 10 52 R80 HK Pays Flag Added Karen 08 NOV 10 51 R79 Writes To PackSlips.X Lou 14 OCT 10 50 R77 Blanked Out PackSlips.X Robert12 OCT 10 49 R75 1 SUB.PACKING.LIST.R75 19 JUL 10 48 R74 Show Insurance $ for UPS, FedEx Karen 15 JUL 10 47 R73 Uses New Ship.To.How Codes 17 JUN 10 46 R71 BaseLine 17 JUN 10 45 R70 Auto Print Quality Label 1 SUB.PACK.SLIP.R42 Robert21 APR 10 44 R69 Enhanced ODBC 18 MAR 10 43 R68 Auto Switch Ship.Via Based.On Weight 11 MAR 10 42 R67 Minor CleanUp 04 MAR 10 41 R66 Bin.To.Bin With SnapShot 1 SUB.BIN.TO.BIN.R50 Mike 25 FEB 10 40 R65 Link Country and Addr Label 26 JAN 10 39 R64 Fixed Show.As.Late Bug 19 JAN 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . [] [##] [II]mpact [KK]ill [NN]ew [SU].I.Am.A.Sub [XX] DICT CHANGES Type Field.Field.FieldConversion..Column. OutputDepth Name..NumberDefinition...CodeHeading FormatAssoc.. @ID D0 CHANGES 10L S APP D0 10L S REV D1 3LM DESC D2 80L M DATE D3 10L M TIME D4 10L M REQUESTOR D5 10L M PROGRAMMERD6 10L M
Re: [U2] Version Control
Hi Bill: The U2 world works inside the database. The rest of the world thinks source code control should be outside the database. Your use of VOC is very unique and probably applicable to a small set of the U2 community. Source code control, except for U2, is done from the local workstation and not on the server. When I was a Configuration Manager for a telecom software company, many moons ago, we did not store any changes inside either the Informix or Sybase databases. We stored all of source code revisions on several Unix boxes that the programmers had to check out and check in from their workstations. I have created a web page that shows how Eclipse maintains a local version. There is a graphic of what U2 project looks like as well as few more. You need to look at the last graphic. That is where version control shines and shows you what you checked in and why. The pretty pictures of Eclipse version control using the XLr8Editor plug-ins is feature here and you can click on any of images to enlarge them: http://www.u2logic.com/versioncontrol.html. Regards, Doug www.u2logic.com Universe and Unidata Eclipse based tool supplier ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Version Control
If you are using U2 environment a lot of stuff won't work without utilising the VOC some fundamental or critical way. VOC entries for files, programs, paragraphs/PROCS, etc. Granted, in some cases these don't change often. Unless you are like some poor sites I have seen and run their entire or parts of their application process from a paragraph or proc in the VOC file - more common than you would like to think or hope! Likewise, control information inside U2 files are in many case extremely critical for many applications - this also needs to be managed and versioned, rolled-back if required, etc., etc. Any configuration management application needs to take everything into account not just source code. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Sent: Friday, 4 March 2011 1:48 PM To: 'U2 Users List' Subject: Re: [U2] Version Control Hi Bill: The U2 world works inside the database. The rest of the world thinks source code control should be outside the database. Your use of VOC is very unique and probably applicable to a small set of the U2 community. Source code control, except for U2, is done from the local workstation and not on the server. ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ** ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
RE: [U2] version control
From: Brian Leach ...The key was to appoint someone who was responsible for it. If it is anything more than trivial, it needs someone charged to administer it, Conan the Librarian not just left to the whims of developers!... Which brings us to the 2nd key: Build in perks for the developers for using version control. It shouldn't be another layer of management that slows them down. Properly implemented, it should be a programmer productivity tool. The more that it helps them be able to compare versions, track what change happened when by whom, lump segregate work, coordinate activity between programmers, do status reporting . . ., the more it directly helps programmers do those tasks, the more enthusiastic they will be, the less likely to circumvent or resent enforcement. I recall implementing it one time where the practice had been to never delete old code, just comment it out and surround changes with date and project numbers comment lines. It got so that a source file had more commented out stuff than actual compilable code. Very difficult to read. When we implemented version control, I suggested that this practice was no longer necessary because they could easily reconstruct pretty pictures of change history. They insisted on doing it the old way, too. Several months later the staff violently revolted against their own conservatism and wanted a special internal project just to clean out all that old stuff because version control was so good to them. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] version control
Thanks to everyone for their feedback on this. Brian Leach's article was useful, and Edward's advice really gave me a shove in the right direction. It's good to know that others have found Subversion to be an appropriate choice -- maybe I am not that crazy after all. ;^) I have some more to think about re: how best to implement this in our situation, and will likely have more questions later. Best, David Beahm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Re: [u2] version control
Brian, Jerry, and everyone. It is possible to implement source code control that is transparent to the programmer yet capable of supporting complex development and production scenarios with tools and utilities that were designed and written entirely in an MV / Pick / U2 environment. NuControl from Binary Star offers an easily implemented version control solution that will manage multiple projects and multiple libraries (code, working and backup), across multiple systems. It supports basic code, segments, scripts, function libraries, configuration data, DICTS, etc. Compare, rollback, release, etc. blatant ad I'd be happy to demonstrate NuControl from Binary Star can do, including full life-cycle management (promotion). It's easy to use and comes with a full screen, color highlighted programmer's editor. For details: http://www.nuwiki.com/cgi-bin/nuwiki.cgi?display=ABOUT%20SCCS (NuControl supports ALL modern mv environments including UniVerse, UniData, D3, QM Professional and Reality (Northgate). Lee Bacall binarystar.com /blatant ad PRC which is Susan Joslyn's product, offers a unique and capable solution for (and requiring) System Buiilder. http://www.sjplus.com - Original Message - From: Brian Leach [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, April 17, 2008 9:29 AM Subject: RE: [U2] version control Jerry et al I would say good version control - like all code management - is a skill. And more so the more diverse your code base. If you are just hacking away at (say) an old D3 application you can probably get away with a lot. If you need to support multiple versions, platforms, client/server and web tiers, probably half a dozen languages, shared libraries etc. the work involved in just managing that should not be - and all too often is by management - underestimated. Hence my comment. This should not be something that is just put in without thought and left to run by itself. It won't. Time taken to plan this now will pay huge dividends down the line. Time not spent will bite you in the bum. A badly put together versioning system is worse than useless - you won't be able to get out what you need at time of crisis, and you will have become complacent thinking that it is there. In our case we had an excellent developer and DBA who took on the role of managing the version control, and did it extremely well. I'm very thankful, especially when we needed his services. Without one person to manage it, it would have become a mess. I would probably have been the worse culpit. You only really appreciate these things once you've been burned without them (like a good and verified backup strategy!). They need to be approached seriously. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] version control [AD]
Hello Group. Of course I'll barge in - just in case there's anyone who doesn't know! - that there is a solution for change control right within U2. PRC of course. Changes are tracked automatically without any extra steps. All the traditional support, backup copies, merge tools, history/research full audit. Source program files but also dictionaries, control data - even actual data to support emergency data edits. PRC is also a complete framework for implementing IT controls that are visible and flexible. Immediate SOX/other regulatory compliance in a snap. Just in case you didn't know! More information at sjplus.com - or drop me an email. Regards, Susan Joslyn SJ+ Systems Associates, Inc. PRC(r) Real software configuration management for U2! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Beahm Sent: 16 April 2008 21:22 To: u2-users@listserver.u2ug.org Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done s something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.1/1384 - Release Date: 4/17/2008 3:47 PM --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] version control
Hello, Have followed this thread with some interest as we've recently moved to Subversion. This hosts VB6 and unidata source code / dicts / various control data for a fairly large set of products. Subversion has met our expectations; we'd dabbled with sourcesafe before but never really had a revision backup strategy. In general, we've found it best to (sorry for stating the obvious with some of these!): - Have as much data in directory files as possible, adding a 'normal' unidata file to subversion does not allow for proper control over each item within that file - Settle on the repository layout at the start - in our case, taking (mostly enforced) advice from subversion users elsewhere in the company and adapting to our local needs. We have separate repositories for each product group with top level 'branches', 'tags' 'trunk' nodes. Bug fixes go into the 'branches' area, each bug being a copy of the trunk. Tags contains snapshots of the trunk at release points. - Branches - Bug1 - (structure) - Bug2 - (structure) - Trunk - (structure) Within (structure) we hold essentially a small unidata account, we develop in another account with pointers back to the subversioned area. This allows a mixture of content kept under source control plus data local settings that we'd not want cluttering up subversion. Lastly, when switching branches it can take a long time to recompile / recatalog the unibasic code; I've written a utility that detects changes by comparing object source date and just compiles what's needed. For us, it reduces a 5 - 10 minute task down to just a few seconds, and is quick enough to use regularly during development if several programs are being edited. I can make the source available if anyone's interested? Edward -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: 18 April 2008 13:26 To: u2-users@listserver.u2ug.org Subject: RE: [U2] version control [AD] Hello Group. Of course I'll barge in - just in case there's anyone who doesn't know! - that there is a solution for change control right within U2. PRC of course. Changes are tracked automatically without any extra steps. All the traditional support, backup copies, merge tools, history/research full audit. Source program files but also dictionaries, control data - even actual data to support emergency data edits. PRC is also a complete framework for implementing IT controls that are visible and flexible. Immediate SOX/other regulatory compliance in a snap. Just in case you didn't know! More information at sjplus.com - or drop me an email. Regards, Susan Joslyn SJ+ Systems Associates, Inc. PRC(r) Real software configuration management for U2! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Beahm Sent: 16 April 2008 21:22 To: u2-users@listserver.u2ug.org Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done s something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.1/1384 - Release Date: 4/17/2008 3:47 PM --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- Please remember to recycle wherever possible. Reduce, reuse, recycle, think do you need to print this e-mail? --- This e-mail and any attachment(s), is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the addressee, dissemination, copying or use of this e-mail or any of its content is prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail, any attachment(s) and any copies. All liability for viruses is excluded to the fullest extent permitted by law. It is your responsibility to scan or otherwise check
Re: [U2] version control
Hello, can I get a copy I am definitely interested as we too are moving to subversion thanks dougc Edward Brown wrote: Hello, Have followed this thread with some interest as we've recently moved to Subversion. This hosts VB6 and unidata source code / dicts / various control data for a fairly large set of products. Subversion has met our expectations; we'd dabbled with sourcesafe before but never really had a revision backup strategy. In general, we've found it best to (sorry for stating the obvious with some of these!): - Have as much data in directory files as possible, adding a 'normal' unidata file to subversion does not allow for proper control over each item within that file - Settle on the repository layout at the start - in our case, taking (mostly enforced) advice from subversion users elsewhere in the company and adapting to our local needs. We have separate repositories for each product group with top level 'branches', 'tags' 'trunk' nodes. Bug fixes go into the 'branches' area, each bug being a copy of the trunk. Tags contains snapshots of the trunk at release points. - Branches - Bug1 - (structure) - Bug2 - (structure) - Trunk - (structure) Within (structure) we hold essentially a small unidata account, we develop in another account with pointers back to the subversioned area. This allows a mixture of content kept under source control plus data local settings that we'd not want cluttering up subversion. Lastly, when switching branches it can take a long time to recompile / recatalog the unibasic code; I've written a utility that detects changes by comparing object source date and just compiles what's needed. For us, it reduces a 5 - 10 minute task down to just a few seconds, and is quick enough to use regularly during development if several programs are being edited. I can make the source available if anyone's interested? Edward -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: 18 April 2008 13:26 To: u2-users@listserver.u2ug.org Subject: RE: [U2] version control [AD] Hello Group. Of course I'll barge in - just in case there's anyone who doesn't know! - that there is a solution for change control right within U2. PRC of course. Changes are tracked automatically without any extra steps. All the traditional support, backup copies, merge tools, history/research full audit. Source program files but also dictionaries, control data - even actual data to support emergency data edits. PRC is also a complete framework for implementing IT controls that are visible and flexible. Immediate SOX/other regulatory compliance in a snap. Just in case you didn't know! More information at sjplus.com - or drop me an email. Regards, Susan Joslyn SJ+ Systems Associates, Inc. PRC(r) Real software configuration management for U2! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Beahm Sent: 16 April 2008 21:22 To: u2-users@listserver.u2ug.org Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done s something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.1/1384 - Release Date: 4/17/2008 3:47 PM --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- Please remember to recycle wherever possible. Reduce, reuse, recycle, think do you need to print this e-mail? --- This e-mail and any attachment(s), is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the addressee, dissemination, copying or use of this e-mail or any of its content is prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail, any attachment(s) and any copies. All liability for viruses
RE: [U2] version control
David You might want to check out an article I wrote for Spectrum about this. Back-issues are on www.intl-spectrum.com. One other tip: We used CVS at my last company, which was quite a complex arrangement handling server and client side code (and keeping these in sync). The key was to appoint someone who was responsible for it. If it is anything more than trivial, it needs someone charged to administer it, not just left to the whims of developers! That was the best decision we made... Regards Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Beahm Sent: 16 April 2008 21:22 To: u2-users@listserver.u2ug.org Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done s something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] version control
It seems that everyone needs to be a specialist these days, even in our business. Jerry Banker Senior Programmer Analyst IBM Certified Solutions Expert -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Thursday, April 17, 2008 4:14 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] version control David You might want to check out an article I wrote for Spectrum about this. Back-issues are on www.intl-spectrum.com. One other tip: We used CVS at my last company, which was quite a complex arrangement handling server and client side code (and keeping these in sync). The key was to appoint someone who was responsible for it. If it is anything more than trivial, it needs someone charged to administer it, not just left to the whims of developers! That was the best decision we made... Regards Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Beahm Sent: 16 April 2008 21:22 To: u2-users@listserver.u2ug.org Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done s something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] version control
David, We use CVS here. We store all of our source code in a flat file/directory structure. We use an OS level build script to generate the accounts, create the files and dictionaries, and load them with data. The primary goal in our situation was to create a one-step build for our product, where the entire product would be generated from the ground up. Patches for production systems are created by diff'ing the prior and current release. We keep each account as separate CVS module, but it doesn't really matter; all accounts could have been in the same module if we designed it that way. The structure we have is: account/src/filename/DATA/record account/src/filename/DICT/record for example, the dict item NAME for the CUSTOMERS file would be stored in AR/src/CUSTOMERS/DICT/NAME Where the src and DICT directories provide metadata for the build script, i.e. src contains U2 files to create (in this case CUSTOMERS), and the load DICT portion of the file with the source item NAME. Note that we could have structured this a lot of different ways to get the same result. File type, modulo, and separation are also stored as metadata; for the CUSTOMERS dictionary file above, it would be stored in AR/src/CUSTOMERS/DICT/_FILE_SIZE. Gotcha's: Depending on Windows vs. Unix, certain filenames or characters within the filename need to be encoded, e.g. CON and AUX conflict with the DOS command line, and * and can also have special meaning. Universe uses %A for an asterisk, etc. and you'll need to do something similar (you could write a function that uses url encoding that also encodes DOS keywords). Suggestion: I wrote an ACCOUNT2DIR utility to create our flat file/directory structure. I was able to tweak it and rerun it until I got the strucure I liked. I suggest that you do something similar so you can easily tryout different structures. rex David Beahm wrote: We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] version control
Jerry et al I would say good version control - like all code management - is a skill. And more so the more diverse your code base. If you are just hacking away at (say) an old D3 application you can probably get away with a lot. If you need to support multiple versions, platforms, client/server and web tiers, probably half a dozen languages, shared libraries etc. the work involved in just managing that should not be - and all too often is by management - underestimated. Hence my comment. This should not be something that is just put in without thought and left to run by itself. It won't. Time taken to plan this now will pay huge dividends down the line. Time not spent will bite you in the bum. A badly put together versioning system is worse than useless - you won't be able to get out what you need at time of crisis, and you will have become complacent thinking that it is there. In our case we had an excellent developer and DBA who took on the role of managing the version control, and did it extremely well. I'm very thankful, especially when we needed his services. Without one person to manage it, it would have become a mess. I would probably have been the worse culpit. You only really appreciate these things once you've been burned without them (like a good and verified backup strategy!). They need to be approached seriously. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JPB-U2UG Sent: 17 April 2008 13:54 To: u2-users@listserver.u2ug.org Subject: RE: [U2] version control It seems that everyone needs to be a specialist these days, even in our business. Jerry Banker Senior Programmer Analyst IBM Certified Solutions Expert -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Thursday, April 17, 2008 4:14 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] version control David You might want to check out an article I wrote for Spectrum about this. Back-issues are on www.intl-spectrum.com. One other tip: We used CVS at my last company, which was quite a complex arrangement handling server and client side code (and keeping these in sync). The key was to appoint someone who was responsible for it. If it is anything more than trivial, it needs someone charged to administer it, not just left to the whims of developers! That was the best decision we made... Regards Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Beahm Sent: 16 April 2008 21:22 To: u2-users@listserver.u2ug.org Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done s something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] version control
David, One other item: in managing development, testing, and production accounts, I've found it easier to use relative Q-pointers in the software. So instead setting the Q-pointer: CUSTOMERS 0001: Q 0002: AR 0003: CUSTOMERS set it up to use a relative pathname: CUSTOMERS 0001: Q 0002: ../AR 0003: CUSTOMERS Every developer can maintain their own unique directory with their own copy of the account(s) they need, without having to setup a STEVE.AR, BOB.AR, or JIM.AR account. rex David Beahm wrote: First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] version control
We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] version control
We use Subversion with a Universe based system. The one piece of advice I would give is to split up the program files or xxPROCESS into logical SVN projects as we found that with a PROGS file of 2500+ programs it would take quite some time to update/commit etc. In the end we also wrote our own mechanism to deploy from SVN a branch out and compile the programs. Another product we use as we have a team of developers all working on similar code is a program called WinMerge which allows easy side by side comparison of programs. David - Original Message - From: David Beahm [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, April 16, 2008 9:22 PM Subject: [U2] version control We are looking to add our UniData/SBClient environment to Subversion, and wanted to get advice from anyone who has done something similar (CVS, etc.) Searching through past posts, I found Brian Leach's note about generating DICT items from scripts, which I quite like; I suspect there are more ideas like that around. First, however, we need to come up with a suitable repository structure. We have a number of live, proto, and development accounts on one box (HP-UX). We have some universally shared directory files, but most files are unique to each account. To begin with, we are wondering whether it would be best to have individual repositories for each account, or whether there should be one repository with relative paths for each account, or whether each account should be a different branch, etc. Suggestions welcome, however we are want to standardize on one solution -- Subversion. Thanks, David Beahm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
