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.
For example, a form in VSS is a binary file. It has had 16 changes to in over the past few years. We would like to have these historical changes stored in git allowing us to reference this history without the need to go back to VSS. The catch is, we only want to store the text equivalent of the form in git.
Is there someone out there that has done this in the past?
Thank you, Tracy
Hi Tracy:
I've done that in 2014 to migrate the last 10 labeled versions from our VSS projects to PlasticSCM repositories.
The simplest way I'd find to do it is to checkout each version, copy to the new repository and checkin into PlasticSCM.
In our case we migrated tx2 files and binaries, but you can do it with just tx2 files. Special care must by take with moved or renamed files. I did the migration of those 10 latest versions (2700 files between tx2 and binaries) in an hour or so.
Because the tx2 are the same, there is no need for regeneration.
Hope this helps,
Best Regards!
El jue., 3 ene. 2019 17:29, Tracy Pearson tracy@powerchurch.com escribi贸:
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.
For example, a form in VSS is a binary file. It has had 16 changes to in over the past few years. We would like to have these historical changes stored in git allowing us to reference this history without the need to go back to VSS. The catch is, we only want to store the text equivalent of the form in git.
Is there someone out there that has done this in the past?
Thank you, Tracy
[excessive quoting removed by server]
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.
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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
Before FB2P was released I would have recommended SCCTEXTX as it did address all the shortcomings of the VFP supplied SCCTEXT tool. But FB2P works brilliantly, has tools to add it to Explorer's Send To menu, and seamlessly handles two way conversions of VFP binaries. Highly recommended as John Dvorak used to say in PCMag...
I've also started playing with PEx and Git for the same reasons as you; getting out of VSS. I can't speak to the preservation of SCC history in terms of a migration but the general integration of PEx with Git works in a manner very similar to the native Project Explorer SCC integration. Getting that initial dump into Git and in general getting comfortable with Git is my biggest hurdle so far. But I'm determined to make the migration in 2019.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Friday, January 4, 2019 4:25 PM To: profoxtech@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
I did find something that converts straight from VSS to git. And it has shown itself to be quick. Though the way I used VSS has some deeply nested projects. This tool is putting everything that deep, leaving a lot of blank folders to move through.
https://github.com/trevorr/vss2git
Though I haven't worked out how to catch and put in the FoxBin2PRG conversion of the binary files yet.
Have a look. I know it will make my life somewhat easier. It keeps all the history.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye Sent: Friday, January 04, 2019 5:05 PM To: profoxtech@leafe.com Subject: RE: VSS to git conversion
Before FB2P was released I would have recommended SCCTEXTX as it did address all the shortcomings of the VFP supplied SCCTEXT tool. But FB2P works brilliantly, has tools to add it to Explorer's Send To menu, and seamlessly handles two way conversions of VFP binaries. Highly recommended as John Dvorak used to say in PCMag...
I've also started playing with PEx and Git for the same reasons as you; getting out of VSS. I can't speak to the preservation of SCC history in terms of a migration but the general integration of PEx with Git works in a manner very similar to the native Project Explorer SCC integration. Getting that initial dump into Git and in general getting comfortable with Git is my biggest hurdle so far. But I'm determined to make the migration in 2019.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Friday, January 4, 2019 4:25 PM To: profoxtech@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
[excessive quoting removed by server]
Thanks, Tracy. That looks quite promising.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: Friday, January 4, 2019 7:32 PM To: profoxtech@leafe.com Subject: RE: VSS to git conversion
I did find something that converts straight from VSS to git. And it has shown itself to be quick. Though the way I used VSS has some deeply nested projects. This tool is putting everything that deep, leaving a lot of blank folders to move through.
https://github.com/trevorr/vss2git
Though I haven't worked out how to catch and put in the FoxBin2PRG conversion of the binary files yet.
Have a look. I know it will make my life somewhat easier. It keeps all the history.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye Sent: Friday, January 04, 2019 5:05 PM To: profoxtech@leafe.com Subject: RE: VSS to git conversion
Before FB2P was released I would have recommended SCCTEXTX as it did address all the shortcomings of the VFP supplied SCCTEXT tool. But FB2P works brilliantly, has tools to add it to Explorer's Send To menu, and seamlessly handles two way conversions of VFP binaries. Highly recommended as John Dvorak used to say in PCMag...
I've also started playing with PEx and Git for the same reasons as you; getting out of VSS. I can't speak to the preservation of SCC history in terms of a migration but the general integration of PEx with Git works in a manner very similar to the native Project Explorer SCC integration. Getting that initial dump into Git and in general getting comfortable with Git is my biggest hurdle so far. But I'm determined to make the migration in 2019.
--
rk
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 FletcherSJohnson@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-bounces@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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
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" FletcherSJohnson@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 FletcherSJohnson@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-bounces@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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
great post!
Thierry Nivelet FoxinCloud Give your VFP app a new life in the cloud http://foxincloud.com/
Le 9 janv. 2019 脿 08:32, Fernando D. Bozzo fdbozzo@gmail.com a 茅crit :
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" <FletcherSJohnson@yahoo.com mailto:FletcherSJohnson@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 FletcherSJohnson@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-bounces@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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
Great post Fernando!!
Malcolm
----- Original message ----- From: "Fernando D. Bozzo" fdbozzo@gmail.com To: profoxtech@leafe.com 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" FletcherSJohnson@yahoo.comescribi贸:
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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of Tracy PearsonSent: 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 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:profoxtech-bounces@leafe.com] On Behalf Of FletcherJohnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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 thinkyou would have to use it to achieve the non-binary source code control process.
[excessive quoting removed by server]
I will pile on here and also say "Great post!" 馃槉 But I will also add that Doug Hennig's ProjectExplorer does allow you to use the project as your base of operations while leveraging distributed SCM tools such as Git or Mercurial. It handles the automatic conversion of binaries to text files using FB2P, commits, etc while eliminating the shortcomings of exclusive locking model of VSS. Now climbing the learning curve for Git is another story... 馃槉
https://github.com/DougHennig/ProjectExplorer
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Fernando D. Bozzo Sent: Wednesday, January 9, 2019 2:32 AM To: profoxtech@leafe.com Subject: Re: VSS to git conversion
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" FletcherSJohnson@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 FletcherSJohnson@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-bounces@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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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/CAGQ_Ju=qGHYY+uK9_7e0Xu=Fce0DbEOmeygi... ** 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. Report [OT] Abuse: http://leafe.com/reportAbuse/CAGQ_Ju=qGHYY+uK9_7e0Xu=Fce0DbEOmeygifb+-skmbm_...
Fernando, This is why I'm looking for a way to convert VSS to Git. But during the conversion I want to take out the *.sca/*.vca files and change them to *.sc2/*.vc2 files. Get the history in to Git without being encumbered with VSS clutter.
Thank you for the excellent post.
Richard, The ProjectExplorer is exactly where we are going. I might be adding some menu items that make calls to command line tools to help with branching, pulling, and pushing. This will enable the team to stay inside VFP. Though I understand the importance of knowing how Git really works. Sometimes, it's better to have something help with our workflow, then to have someone not follow a prescribed workflow.
Thank you everyone that is chiming in. I appreciate the conversation.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye Sent: Wednesday, January 09, 2019 8:29 AM To: profoxtech@leafe.com Subject: RE: VSS to git conversion
I will pile on here and also say "Great post!" 馃槉 But I will also add that Doug Hennig's ProjectExplorer does allow you to use the project as your base of operations while leveraging distributed SCM tools such as Git or Mercurial. It handles the automatic conversion of binaries to text files using FB2P, commits, etc while eliminating the shortcomings of exclusive locking model of VSS. Now climbing the learning curve for Git is another story... 馃槉
https://github.com/DougHennig/ProjectExplorer
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Fernando D. Bozzo Sent: Wednesday, January 9, 2019 2:32 AM To: profoxtech@leafe.com Subject: Re: VSS to git conversion
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" FletcherSJohnson@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 FletcherSJohnson@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-bounces@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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
On Jan 9, 2019, at 8:13 AM, Tracy Pearson tracy@powerchurch.com wrote:
This is why I'm looking for a way to convert VSS to Git. But during the conversion I want to take out the *.sca/*.vca files and change them to *.sc2/*.vc2 files. Get the history in to Git without being encumbered with VSS clutter.
Maybe this could provide you with a starting point? https://github.com/trevorr/vss2git
-- Ed Leafe
Ed,
I've been going through that.
Thank you, Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ed Leafe Sent: Wednesday, January 09, 2019 9:55 AM To: profoxtech@leafe.com Subject: Re: VSS to git conversion
On Jan 9, 2019, at 8:13 AM, Tracy Pearson tracy@powerchurch.com wrote:
This is why I'm looking for a way to convert VSS to Git. But during the
conversion I want to take out the *.sca/*.vca files and change them to *.sc2/*.vc2 files. Get the history in to Git without being encumbered with VSS clutter.
Maybe this could provide you with a starting point? https://github.com/trevorr/vss2git
-- Ed Leafe
[excessive quoting removed by server]
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 fdbozzo@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" FletcherSJohnson@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 FletcherSJohnson@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-bounces@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-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Friday, January 04, 2019 3:38 PM To: profoxtech@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 FletcherSJohnson@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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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]
Mike,
In the VSS repository we are not currently using FoxBin2PRG. We want to use it in the git repository, keeping the binaries out of it. Doug Hennig's
Thank you, Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Friday, January 04, 2019 3:21 PM To: profoxtech@leafe.com 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]