Living Compiled Scripts and Equally Alive Shared Include Files

[DAG_P6]

It happened again today.

I have a compiled WB script that uses many shared include files. By shared include files, I mean that the include files live in a separate directory, and are incorporated into many scripts, much as a C programmer includes header files that declare library routines.

What happened again today is that I had to change and compile a downlevel version of the script, which has been in production for almost a year. When did so, it pulled the latest versions of the shared include files into the script. Normally, this isn't an issue, but the script in question used some constants that are defined in shared include files, several of which have been given different, more appropriate names.

While I built a mechanism into the include files to work around the issue, using that workaround requires that you know that your program uses the deprecated names. Since this code will soon be superseded by a new version that uses the new names, I didn't scan it for the deprecated names. Consequently, I lost about three hours, about which my client is none too happy (nor am I, FWIW).

From time to time, I have debated whether it would be worthwhile to create a program that identifies all included script files, finds them in the file system, and copies them into the source code directory for archiving.

• Saving copies with the script would guarantee that the include files are consistent with the milestone source code.
• However, keeping the local copies in the active development directory hides the library copies, because the interpreter favors local copies over copies stored elsewhere.
• In an ideal world, there would be a Production source tree, complete with relevant versions of the satellite code files, and a completely separate Development source tree.

What are my colleagues doing to manage these thorny source code control issues?

[kdmoyers]

I'm currently transitioning from a roll-ur-own versioning system to this:

http://www.visualsvn.com/server/
and
http://tortoisesvn.net/

It's way too early to report any success.  however, it's free!

[td]

We use the tagging/labeling and other feature of a version control system along with build automation scripts (WinBatch of course) for production builds.

[DAG_P6]

Thanks to both of you for your inputs.

From time to time, I have considered implementing something along the lines of SubVersion, but it seems like overkill for a one-person shop. Nevertheless, some of my more recent projects have strained the limits of simple version control methods. Hence, I find myself visiting the topic yet again.

One thing that I can't quite get my head around is how a version control system can manage dependencies in something like a WinBatch script that incorporates code by #include. Assuming that the system knows how to make the connections, as it presumably would for a C++ project, it should be straightforward, but that seems to me like it might be a risky assumption.

[JTaylor]

Not sure this will help since I don't do versioning...I [almost] never go back to an old version of something...but when producing my releases I have a script which takes my code and incorporates all the dialogs into the code which allows me to always keep my dialogs separate for development.   If I faced your situation I would probably give my include files an appropriate name with version and/or datetime stamp as part of the name and in the main script indicate the date/version to use.  My include files would have a {TAG} as part of the include file name(s) and my compilation script would create a copy changing the tags to the appropriate version info in the include file names before compiling.   When I knew that a script was updated to use the latest I could simply change the one entry in the main script and the next compile would use different include files. 

Hopefully this makes sense and I haven't missed the point.  Been a long day so my brain may be too weary to think straight :-)

Jim

[DAG_P6]

Jim,

Not sure this will help since I don't do versioning...I [almost] never go back to an old version of something...but when producing my releases I have a script which takes my code and incorporates all the dialogs into the code which allows me to always keep my dialogs separate for development.   If I faced your situation I would probably give my include files an appropriate name with version and/or datetime stamp as part of the name and in the main script indicate the date/version to use.  My include files would have a {TAG} as part of the include file name(s) and my compilation script would create a copy changing the tags to the appropriate version info in the include file names before compiling.   When I knew that a script was updated to use the latest I could simply change the one entry in the main script and the next compile would use different include files. 

I think it makes sense.

If I understand you correctly, when you change an #include file, a version number or modified date is part of its name, and you use that to tell the script which file to import. Is that correct?

[kdmoyers]

One thing that I can't quite get my head around is how a version control system can manage dependencies in something like a WinBatch script that incorporates code by #include.

You're right. I think I missed the original point. SVN isn't, by itself, going to help you.  Jim's idea sounds better.

[JTaylor]

After getting a bit of sleep and pondering this a bit more I might, in your case, do something like the following.  In my case I would probably go the route I mentioned above because of how I already process releases.  Since, I assume, you don't pre-process all your files that would be an extra step for you.  The substitution could obviously be a directory name rather than part of the file name which would allow you to keep the same file names and separate the versions by directory, which probably is easier and makes more sense.

Jim

Code (winbatch) Select Expand



versioning=1

inc = '#include ".\include_1_v%versioning%.wbt"'
%inc%
inc = '#include ".\include_2_v%versioning%.wbt"'
%inc%


[td]

Thanks to both of you for your inputs.

From time to time, I have considered implementing something along the lines of SubVersion, but it seems like overkill for a one-person shop. Nevertheless, some of my more recent projects have strained the limits of simple version control methods. Hence, I find myself visiting the topic yet again.

One thing that I can't quite get my head around is how a version control system can manage dependencies in something like a WinBatch script that incorporates code by #include. Assuming that the system knows how to make the connections, as it presumably would for a C++ project, it should be straightforward, but that seems to me like it might be a risky assumption.

It sounds like you are confusing version control with its integration into a development environment. One of the main purposes of any version control system is to associating files with projects and  versions of files with versions of projects irrespective of development tool integration.  WinBatch scripts are no different than C++ source code with respect to version control sans other development tools. That said, I do use a very basic but effect enough integration of  version control  into WinBatch Studio via user tool buttons and context menu scripts. It isn't nearly as slick as MSFT's VS team system setup or some of the other highly integrated development environments but it does the job without of addition effort.     

[DAG_P6]

Tony,

It sounds like you are confusing version control with its integration into a development environment.

Not really. The uncertainty regards the way the version control system identifies dependencies in a project. While dependency identification rules are well defined for C++ and C# projects, what about WinBatch projects?

[td]

Generally, source code management systems are programming language agnostic.  Project version dependency rules for files and versions of those files are determined by the user.  I use one system for all my projects and establish projects dependencies in the same way whether they be a single language, a mix of languages, C++, C, C#, PHP, WIL, or any number of other languages I use. 

The merits of source code management systems are well established. They are trivially easy to set up for a small shop, can be obtained at no cost and have benefits well beyond what is mentioned above.