Great post Fernando!! Malcolm
----- Original message ----- From: "Fernando D. Bozzo" <[email protected]> To: [email protected] Subject: Re: VSS to git conversion Date: Wed, 9 Jan 2019 08:32:19 +0100 When people leave VSS for a new SCM tool, one of the first mistakes thatmany of them make is to try to use the new SCM tool in the same way thatthey used VSS, and they do not realize that the new SCM tools are designedWith a different mindset and considering a different work flow, it is anevolution of the old way of doing things. If one tries to change this type of tool for a new one with the same mentality and is not evolving in the way of doing things, then he could notobtain the benefits of the new way of doing things and he will simply repeat what he knows. Applying this to VFP, many people try to use something like Git or similarwith the same workflow they used with VSS, for example, blocking modifiedfiles so that no one else can modify them, and doing this is in the 21stcentury on a computer local or distributed, it's a huge mistake. Some of those benefits are speed, concurrency and independence. Speed because allowing several people to work on the same component is better and faster than one at a time Concurrence due to the same, 2 or more people can work in different arrangements or functions in the same component at the same time withoutblocking each other Independence because if one of the people who works on a component (form,class library) leaves the edition open and leaves (vacation, illness, etc.), nobody is blocked and others can continue working on it. VSS treated the files independently, one by one, and this is one of thegreat changes with the new tools, since they are no longer individual files, now there is a set of changes composed of many modified files related to the task, for what when you need to know what files were modified for a solution / feature, you can know. VSS was useful at the time with the mentality of its time, but now thereare better ways of doing things and thinking about the code and if you wantto make that transition and improve the way you work with the code, then itis convenient to learn how to do it as it is done now, although really thenew way of working has already been in existence for more than 15 years. The best way to take advantage of all this in VFP is not to tie yourself tothe VSS way of doing things, not to think about files but about features orarrangements, and focus on that. Forget SccText and what was already generated with it and regenerate all text files with FoxBin2Prg to startbenefiting from being able to make code mixes like the rest of the languages do. The branches by task help to work in this way. VSS could not work with branches in a useful or efficient way, now it can and is very useful, sinceyou can be working on several features and arrangements at the same timewithout interfering with each other. Many of the changes in the way of work have to do also with the new way ofmaking the code mixes, the composition of the components through the different contributions of the developers, something unimaginable with VSS. Finally, leave open the possibility of not wanting to continue controllingeverything from the project manager, which is very comfortable for the oldway of working, but it is not efficient when you can be working on one feature at a time and the next moment you have to leave all by halves andcontinue working in another branch for an important arrangement. In order to do this, it is better and more efficient to separate the management of the VFP project manager code and manage it with the SCM toolchosen, outside of VFP. At first it is difficult to get used to the idea,especially when they have been using the same thing for many years, butthen one gets used to another form of work and discovers the advantagesthat I mention. Best Regards! Fernando D. Bozzo El 9 ene. 2019 2:24 a. m., "Fletcher Johnson" <[email protected]>escribió: Tracy, Now I remember. I actually had a program that I could run that would re-sort the scx (or the generated code) and then re-format the code so thatthe code was always in more or less the same sequence and format. I am guessing that whoever wrote FoxBin2PRG had some of the same frustrations andwas nice enough to build something more robust and then publish it. When VSS support was first added, the theory was that any source controlcould be used. I often wondered if the hooks were still there so that Gitcould be used as (more or less) seamlessly as VSS. I hope things work out, Fletcher Fletcher Johnson [email protected] LinkedIn.com/in/FletcherJohnson beknown.com/FletcherJohnson twitter.com/fletcherJ twitter.com/svcsug strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell -----Original Message----- From: ProFox [mailto:[email protected]] On Behalf Of Tracy PearsonSent: Friday, January 4, 2019 1:25 PM To: [email protected] Subject: RE: VSS to git conversion Fletcher, We used the default SCCTEXT.PRG is what creates the VCA and SCA files storedin VSS next to the binary files. However, attempting to DIFF that did notalways work out well. VFP would move some records around when editing amethod. It would look like a big chunk of the form or class library had beenremoved from higher up, and then added back in down below. Which is actuallythe case, since that code is stored in a memo field. Change a memo field.The old value is still in the FPT until it's packed out. The new value isadded to the end. I understand the FoxBin2PRG fixes that problem. It also enables just thetext version to be stored in the source control because it can be turnedback in to a binary file. Thank you, Tracy -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of FletcherJohnson Sent: Friday, January 04, 2019 3:38 PM To: [email protected] Subject: RE: VSS to git conversion Tracy, My understanding is that bin2prg (or something like it) was created expressly to support what you want to do. The idea was that the dbf (.scx,etc.) would be used to create a comparable prg file and then both would bechecked in. The prg was used for change tracking only. It worked greatwith VSS - not sure how well it will work with Git using the VFP projectmanager, but you should be able to create a script that will do effectivelythe same thing. Fletcher Fletcher Johnson [email protected] LinkedIn.com/in/FletcherJohnson beknown.com/FletcherJohnson twitter.com/fletcherJ twitter.com/svcsug strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell -----Original Message----- From: ProFox [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, January 4, 2019 12:21 PM To: ProFox Email List Subject: Re: VSS to git conversion On 2019-01-03 11:29, Tracy Pearson wrote: > We are looking at changing things over from VSS to git. There > are about> 20 > projects that we want to transfer the history of the files in to git.> > However, we do not want to transfer the binary files over. We haven't> been > using the FoxBin2PRG since we have been just working directly in the > standard project manager in VFP. Hi Tracy...Happy New Year! Did you mean to say that you ARE or ARE NOT using FoxBin2PRG? I'd thinkyou would have to use it to achieve the non-binary source code control process. [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/1547037101.1741000.1629769296.4d8fd...@webmail.messagingengine.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
