RE: [U2] Source Code Management
Karen I originally used to use RCS under UniVerse with some simple verbs that committed items in and out of a work directory using an index file to map account|file|item paths to work file keys. This meant that I could easily manage items from hashed files (eg dictionaries) using some simple RCSPUT, RCSGET, RCSLOG type verbs. It was simple and worked pretty well, and I should have the source code somewhere waiting to dig out and clean up when I get a chance. Later on we went to CVS, using commit/extract scripts under UNIX and TortoiseCVS with Windows. The reason was that we needed to integrate source control from a wider set of locations: UniVerse code for the server routines as well as all the client stuff (VB, Delphi, resources, web pages etc). Keeping these in step was a major exercise, especially since we had a lot of shared libraries and common modules between projects. One simple thing that helped us hugely, was writing some simple commands that generated all of the dictionaries, INI file entries, data items etc that we needed on the server side from scripts. This meant that the scripts were part of the 'source code', held in type 19 files and CVS'ed with the rest of the source. We also added scripting (two way generation) to our windows development environment, for the same reason. One thing to be aware of. Changing revision control strategies at a later date is a major pain. I know this may sound obvious, but think ahead to what you will need to control in order to ensure that you have every base covered. If you are only doing server based work, that is all you need to scope: but if you are adding other interfaces, make sure sure your solution will work with those as well! Also (sorry if this sounds heavy): revision control is not something to approach lightly. It takes planning and resource. We learned (the hard way) to include it in project plans, and to make it a specific routine task for systems administration. A poorly or partially implemented revision control doesn't help anyone, so make sure you get the buy-in and budget for it: tools like RCS, CVS etc. may be free but there is an ongoing cost in managing any solution. I haven't used the highly-regarded and oft-quoted PRC so I don't know if it works with multiple environments, but a commercial system may be a cost saving in the end. Managing a good revision control strategy is a headache for someone and an overhead for everyone: but however much management it takes, it is still a lot less than the time and expense of trying to reconstruct a revision when you haven't got everything in place. It only takes one disaster... Brian Burned and Learned --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Source Code Management
We too used RCS for some time later moving to Microsoft Source Safe (our developers work on Windows). We don't have anything special made for it - we simply have Work directory set to a developer's account. It is easier for us as we have a in-house developed editor for uniBasic that understands read-only attribute on files and we keep our dictionary description in XML files (i.e. the actual dictionary is automatically created when the XML file is changed in our source editor). - Original Message - From: Brian Leach [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 10:36 AM Subject: RE: [U2] Source Code Management Karen I originally used to use RCS under UniVerse with some simple verbs that committed items in and out of a work directory using an index file to map account|file|item paths to work file keys. This meant that I could easily manage items from hashed files (eg dictionaries) using some simple RCSPUT, RCSGET, RCSLOG type verbs. It was simple and worked pretty well, and I should have the source code somewhere waiting to dig out and clean up when I get a chance. Later on we went to CVS, using commit/extract scripts under UNIX and TortoiseCVS with Windows. The reason was that we needed to integrate source control from a wider set of locations: UniVerse code for the server routines as well as all the client stuff (VB, Delphi, resources, web pages etc). Keeping these in step was a major exercise, especially since we had a lot of shared libraries and common modules between projects. One simple thing that helped us hugely, was writing some simple commands that generated all of the dictionaries, INI file entries, data items etc that we needed on the server side from scripts. This meant that the scripts were part of the 'source code', held in type 19 files and CVS'ed with the rest of the source. We also added scripting (two way generation) to our windows development environment, for the same reason. One thing to be aware of. Changing revision control strategies at a later date is a major pain. I know this may sound obvious, but think ahead to what you will need to control in order to ensure that you have every base covered. If you are only doing server based work, that is all you need to scope: but if you are adding other interfaces, make sure sure your solution will work with those as well! Also (sorry if this sounds heavy): revision control is not something to approach lightly. It takes planning and resource. We learned (the hard way) to include it in project plans, and to make it a specific routine task for systems administration. A poorly or partially implemented revision control doesn't help anyone, so make sure you get the buy-in and budget for it: tools like RCS, CVS etc. may be free but there is an ongoing cost in managing any solution. I haven't used the highly-regarded and oft-quoted PRC so I don't know if it works with multiple environments, but a commercial system may be a cost saving in the end. Managing a good revision control strategy is a headache for someone and an overhead for everyone: but however much management it takes, it is still a lot less than the time and expense of trying to reconstruct a revision when you haven't got everything in place. It only takes one disaster... Brian Burned and Learned --- 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] Source Code Management
I'm glad Brian stepped up with his comments below. There is a difference between source control and software management. Everyone has different requirements so when someone says I need source control and everyone chimes in with CVS, etc, it's like proposing a helicopter to someone who needs transportation - a more appropriate solution might be a bike or car or airplane, depending on their needs. And people need to understand that asking for something generic like source control may not really be in line with their long-term needs. The last thing you want is for someone to say great, we can commit and rollback, now I want bug tracking and some other reporting for that. PRC is the standard in our market for such tools but that could be a bit high-end for many developes because it includes so much beyond simple version control. I'm told in other similar forum discussions that Perforce is an excellent tool for mainstream developers. http://perforce.org/eng/index.php?section=1 Unfortunately they don't handle hashed files, which brings us back to one of the advantages of PRC. Tony Brian Leach wrote: Also (sorry if this sounds heavy): revision control is not something to approach lightly. It takes planning and resource. We learned (the hard way) to include it in project plans, and to make it a specific routine task for systems administration. A poorly or partially implemented revision control doesn't help anyone, so make sure you get the buy-in and budget for it: tools like RCS, CVS etc. may be free but there is an ongoing cost in managing any solution. I haven't used the highly-regarded and oft-quoted PRC so I don't know if it works with multiple environments, but a commercial system may be a cost saving in the end. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Source Code Management
My experience with Perforce is that it is very pricy. Separate license for each person that will access or contribute to the data. It is a good solution and being outside of the MV environment has some advantages as far as security is concerned. I have also worked with PRC and it is definitely the standard. It has a lot of capability, but you don't have to use it all. It is very configurable, through control files and some what through modifications to SB+ items. I found PRC more natural than Perforce, but then MV is more natural to me. Tom Dodds [EMAIL PROTECTED] 630-235-2975 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Friday, September 30, 2005 3:58 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Source Code Management I'm glad Brian stepped up with his comments below. There is a difference between source control and software management. Everyone has different requirements so when someone says I need source control and everyone chimes in with CVS, etc, it's like proposing a helicopter to someone who needs transportation - a more appropriate solution might be a bike or car or airplane, depending on their needs. And people need to understand that asking for something generic like source control may not really be in line with their long-term needs. The last thing you want is for someone to say great, we can commit and rollback, now I want bug tracking and some other reporting for that. PRC is the standard in our market for such tools but that could be a bit high-end for many developes because it includes so much beyond simple version control. I'm told in other similar forum discussions that Perforce is an excellent tool for mainstream developers. http://perforce.org/eng/index.php?section=1 Unfortunately they don't handle hashed files, which brings us back to one of the advantages of PRC. Tony Brian Leach wrote: Also (sorry if this sounds heavy): revision control is not something to approach lightly. It takes planning and resource. We learned (the hard way) to include it in project plans, and to make it a specific routine task for systems administration. A poorly or partially implemented revision control doesn't help anyone, so make sure you get the buy-in and budget for it: tools like RCS, CVS etc. may be free but there is an ongoing cost in managing any solution. I haven't used the highly-regarded and oft-quoted PRC so I don't know if it works with multiple environments, but a commercial system may be a cost saving in the end. --- 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] Source Code Management
We use CVS here. All file size info, dictionaries, VOC pointers, and other source code are checked into CVS. Artifacts that can be generated from source code are left out. TortoiseCVS is a windows client for CVS that makes it easy to look thru the scc library. If I had to do it all over again, though, I'd opt for using Subversion and TortoiseSVN). When using any source code control system, it's important to have a one-step build process to checkout all the source code and generate a complete system (for testing or distribution.) Too often, someone needs to slip in just one more fix and if the build process has a lot of steps (or heaven forbid, manual steps) tasks get skipped. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 29, 2005 2:11 PM To: u2-users@listserver.u2ug.org Subject: [U2] Source Code Management All, The thread regarding the good programming practices and comments regarding versioning raised some questions for me. What tool are you using for source code management? What are its benefits and disadvantages? I'm specifically interested in version controlpreferably Unix-based. If you have vendor information, please provide that as well. In a previous life, I used something called sccs - I don't know if it's a current offering in the marketplace? Thanks!!! Karen Bessel Programmer/Analyst Ferguson Enterprises Inc. --- 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/
