Hi Tom, The use of the VC_Framework component is completely independent of the version control system. I don't know much about the Team Foundation Server, but in AFAIK it has means to manage the source code.
But again, the approach works with 4D and the import functionality of the VC_Framework component, but has two limitations: - Performing an additional step after checking out the code from the source code administration. The steps are: 1. you need to open a method that you are sure is not included in the current changeset. This is because you cannot import methods that are already open in 4D. 2. Then you need to select the import macro. This will trigger the import method within the component. The rest runs automatically. It is always a good idea to perform a syntax check afterwards. - The other thing is that methods cannot be deleted during the import. The automatic export by the component deletes previously exported methods, but the re-import is not able to do this. So you have to do this manually and you have to communicate with your team about deleted methods. I would recommend from time to time to use a new central copy of the 4D structure file and to do a re-import. There are so many things besides forms that are not handled by the component, e.g. changes in the database structure. We copy the current structure file to certain archive folders on our file server during the build process so that we can use that copy. But besides all the problems, we have been using the component very successfully for years. We are used to doing the additional steps now, that's not a real problem, you have to keep it in mind. Regards Lutz Epperlein > -----Original Message----- > From: 4D_Tech [mailto:4d_tech-boun...@lists.4d.com] On Behalf Of Tom Benedict > via > 4D_Tech > > Hi Lutz, > > Sorry to bug you again, but we’re moving forward on a project where we are > consulting > with a client who is setting up an agile development team to use 4D. They > will be > managing this team with Microsoft Team Foundation Server. I’m thinking that > TFS > should be able to serve as a repository for the 4D code (methods and forms) > using the > VC_Framework component that you have updated. > > > We have been doing something similar for some time with the VC_Framework > component. The original version of the component doesn't support the > re-import of > code so we extended it with an import function for methods. The procedure is > a bit > inconvenient, you have to do an additional step (the import) manually after > checking > out the code from the versioning system (Mercurial in our case) but it works > flawlessly. > We use this workflow and the vc_framework component since 4d V13. Look here > if you > are interested: https://github.com/elutz/vc-framework-v17 > <https://github.com/elutz/vc-framework-v17> > The part that isn’t completely clear to me is the Build/Release Management > part. I’m > trying to figure now is how to link code in the repository to TFS work items > so that the > release manifest that TFS produces includes all the methods and forms which > are code > complete and validated by QA. In your process, how do you know which methods > to > import? > > Tom Benedict > ********************************************************************* > * > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************* > * ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
