Well stated. I am lead on a project to replace VSS with a new tool. The team gets really pissed when it doesn't work exactly like VSS does.
I am saving this text to share at the next meeting. On Wed, Jan 9, 2019 at 1:33 AM Fernando D. Bozzo <fdbo...@gmail.com> wrote: > When people leave VSS for a new SCM tool, one of the first mistakes that > many of them make is to try to use the new SCM tool in the same way that > they used VSS, and they do not realize that the new SCM tools are designed > With a different mindset and considering a different work flow, it is an > evolution 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 not > obtain 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 similar > with the same workflow they used with VSS, for example, blocking modified > files so that no one else can modify them, and doing this is in the 21st > century 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 without > blocking 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 the > great 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 there > are better ways of doing things and thinking about the code and if you want > to make that transition and improve the way you work with the code, then it > is convenient to learn how to do it as it is done now, although really the > new 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 to > the VSS way of doing things, not to think about files but about features or > arrangements, and focus on that. Forget SccText and what was already > generated with it and regenerate all text files with FoxBin2Prg to start > benefiting 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, since > you can be working on several features and arrangements at the same time > without interfering with each other. > > Many of the changes in the way of work have to do also with the new way of > making 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 controlling > everything from the project manager, which is very comfortable for the old > way 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 and > continue 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 tool > chosen, 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, but > then one gets used to another form of work and discovers the advantages > that I mention. > > Best Regards! > > Fernando D. Bozzo > > > > El 9 ene. 2019 2:24 a. m., "Fletcher Johnson" <fletchersjohn...@yahoo.com> > 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 that > the 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 > and > was nice enough to build something more robust and then publish it. > > When VSS support was first added, the theory was that any source control > could be used. I often wondered if the hooks were still there so that Git > could be used as (more or less) seamlessly as VSS. > > I hope things work out, > > > Fletcher > > > Fletcher Johnson > fletchersjohn...@yahoo.com > 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:profox-boun...@leafe.com] On Behalf Of Tracy Pearson > Sent: Friday, January 4, 2019 1:25 PM > To: profox@leafe.com > Subject: RE: VSS to git conversion > > Fletcher, > > We used the default SCCTEXT.PRG is what creates the VCA and SCA files > stored > in VSS next to the binary files. However, attempting to DIFF that did not > always work out well. VFP would move some records around when editing a > method. It would look like a big chunk of the form or class library had > been > removed from higher up, and then added back in down below. Which is > actually > the 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 is > added to the end. > > I understand the FoxBin2PRG fixes that problem. It also enables just the > text version to be stored in the source control because it can be turned > back in to a binary file. > > > Thank you, > Tracy > > > -----Original Message----- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of > Fletcher > Johnson > Sent: Friday, January 04, 2019 3:38 PM > To: profoxt...@leafe.com > 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 be > checked in. The prg was used for change tracking only. It worked great > with VSS - not sure how well it will work with Git using the VFP project > manager, but you should be able to create a script that will do effectively > the same thing. > > Fletcher > > > Fletcher Johnson > fletchersjohn...@yahoo.com > 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:profox-boun...@leafe.com] On Behalf Of > mbsoftwaresoluti...@mbsoftwaresolutions.com > 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 think > you would have to use it to achieve the non-binary source code control > process. > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com 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/CAJidMY+ikRXm4RD3sm2uOToyHw6M14+SSKFgHRkgdmOez4=j...@mail.gmail.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.
