Lutz, I work as a solo developer for the most part and have tried nearly all the code archiving/management schemes mentioned so far. As everyone is saying they have their pros and cons.
For a long time I've been exporting methods grouped by modification date. Basically a one method scheme - set up the destination folders, set a small document with the options and parameters (really just the last export date), get list of methods and export the ones changed after the cutoff date to a folder named with the date. Can be triggered manually or set it up for On database close to do it automatically. This creates a lot of files initially then levels off and gets to be pretty useful. Especially because I can call up prior versions of a method using Spotlight. This has saved me a lot of time when I've changed something I need to roll back, didn't duplicate the method first and would otherwise have to find a backup of some sort. The mod date of the code file let's me find the most recent. I noticed the stamp parameter for METHOD GET PATHS not long ago. This is pretty cool. The stamp is a longint that seems to be a serial counter maintained inside of 4D. It gets incremented by doing 'things'. I don't know what those things are exactly and it's clearly a relative indicator specific to the structure file but what it lets you do in this context is get the methods changed since whatever value you pass and returns the current value. If you save that value and pass it the next time you run METHOD GET PATHS you get only methods changed since the last time. This has turned out to be really useful in situations where I'm working on a database with a version jump in the works. Like maintaining v13 while preparing release of v15. The changes in v13 need to get propagated forward - but only the ones I actually changed. Since the export method runs in interpreted mode I can also change code ... so I add a method I call _DEV_METHOD_STAMP if it doesn't already exist when the export method runs. It's a function that returns the stamp for the last time the export ran. I re-write it every time the export runs and it maintains a record of these exports for free. A recent one looks like this: C_LONGINT($0) $0:=17411066 // 4/6/17: 17399613 // 3/16/17: 17393733 // 3/17/17: 17357448 // 3/12/17: 0 The first export happened on 3/12 and so on. This could be expanded, of course, but this is good for me. I really like the function to manage the export threshold - no external docs to get lost or changed. Something this won't catch that Josh's VC did is deleted methods... On Thu, Apr 20, 2017 at 4:46 AM, Epperlein, Lutz (agendo) via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Hi Nigel, > > basically I'm interested, we are following a similar approach. I should > explain it a bit. > > At first we use a modified version of the mentioned vc-framework > component. It saves all changes in the code to text files immediately and > keeps track of the timestamps of the changes in an external database. The > text files can be committed to a source code versioning tool like svn, > mercurial, git ... > This is the basic idea behind the vc-framework. > > We extended it a bit to allow reimporting of the exported code. So we are > able to switch between branches and we can do team development without a > development server and dev clients. All members of our team use single user > instances of 4D. The result of the development will be compiled into a > built/merged server application. > A very old version (V13 yet) with import code can be found on Github: > https://github.com/elutz/vc-framework-v13 > > But there are some disadvantages of this approach, all based on the > limitations of 4D's way to handle the code. > At first, the comparison of the exported and the present code in the > database is based only on timestamps, that is a bit fragile. Most of the > time it works, but if problems are happening the solution is sometimes > difficult and a bit time consuming (re-export and re-import of thousands of > methods). > Another problem is the reliability of the component since 4D V15. Very > often the immediate export of the code doesn't work and you have to trigger > it manually. If the developer forget this additional step, he will check in > only a part of his new code. > Because of that we don't recommend to take it 1:1 regardless we are using > it a quite long time. > As a task we have to invest time to improve and adapt the component to > make it more reliable again. > > I hope, there were some interesting thoughts ... > > Regards > Lutz > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** > -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
