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/
