Version Control

[mytekcontrols]

PicNaut:

Do you keep all of your project's includes in the same folder as your .BAS or .PBP file?

Yes I keep all the include files that the particular "project" requires in the same folder.

Brian:

Maybe I don't understand the problem but mytekcontrols' issue with not backing up include files seems a no brainer to me. I regard include files as a stable piece of code or compiler directives or whatever that was developed previously.

Let me describe how I use include files and perhaps it will make more sense. As I develop a project, I first decide what are the basic things about the project that can be broken into logical modules. This is of course just a first stab at it, since over time I figure out more and more things that can be redivided, or just new functions that I never thought of before. These modules in many cases will be new or unique to this project only. And as such are just as much in development as the main calling module, especially during the early development stages.

In the present StampVue project I am essentially writing an entire operating system in PBP which will end up being somewhere in the area of 40,000 bytes when assembled. I really don't want to scroll through that much code in one piece when I am developing it. Instead what I have done by modularizing it, is break it into more manageable chunks. Here are the present includes from the StampVue Project's calling routine thus far:

'===========================================================================
' Includes
'===========================================================================

Include "mod_DATA.bas"              ' defaults for EEprom
Include "18F2525_DEFINES.bas"       ' specific defines for CPU
Include "EQUATES_stampvue.bas"      ' equates for entire project
Include "IO_stampvue.bas"           ' I/O pin assignments
Include "mod_IRQ.bas"               ' fast ISR module
Include "mod_IRQL.bas"              ' slow ISR module
Include "mod_I2C.bas"               ' video/rtc I2C module
Include "mod_LM1247init.bas"        ' video generator init module
Include "mod_keybd.bas"             ' PS2 keyboard module
Include "mod_messages.bas"          ' text message module
Include "mod_DS1307rtc.bas"         ' rtc low-level routines module
Include "mod_ADCsample.bas"         ' A/D low-level routines module
Include "mod_windows.bas"           ' pop-up windows module
Include "mod_ADCdisp.bas"           ' A/D display module
Include "mod_TIMEdisp.bas"          ' time display module
Include "mod_DATEdisp.bas"          ' date display module
Include "mod_ENCDRdisp.bas"         ' encoder/pulse display module
Include "mod_AUTOconfig.bas"        ' automatic display config module
Include "mod_TXTSCRLconfig.bas"     ' scrolling text config module
Include "mod_HVhueconfig.bas"       ' horz/vert/hue config module
Include "mod_TXTSCRLdisp.bas"       ' scrolling text display module
Include "mod_colorSAMP.bas"         ' color sample chip display module
Include "mod_cbarATTR.bas"          ' color bar attributes module
Include "tbl_keybd.bas"             ' table of keyscan values
Include "tbl_vascii.bas"            ' table for ascii-to-video translation
Include "tbl_asciie.bas"            ' table of re-mapped ROM characters
Include "tbl_messages.bas"

'===========================================================================

Believe me when I say this method of doing things really ends up being a time saver, and not a waste of time. There is also nothing "new" about this method of organizing source code. It is done all the time in Windows, Linux, Unix, ect. application development. Although in those environments there has traditionally been a massive amount of code to develop, something that has just recently begun to creep into the PIC embedded processor world with their ever increasing flash program space.

Brian:

I avoid include files and much prefer to see the whole code in the main file to make sure later (much later) revisions of the main code don't get tripped up by a change to the include file. I copy and paste the old code straight into my new code for completeness.

To each his own, and whatever works for you, is of course the way you should do it. I just do it differently is all.

PicNaut:

I may be able to rig up a routine that first looks to see if your include files are backed up. Then, it only checks each time to see if they've changed. If they have, then they get backed up. This get's messy though. I will probably leave that until later, unless everybody else wants that feature now.

I would certainly like to see this, but it might be worth while to take a poll on who uses multiple include files in their PBP development, in order to get a better feel for the priority of doing so.

As ObiWan would say "may the force be with you",

[picnaut]

Hi Guys and Gals,

I will be away on business next week and I plan to get a lot done on the basic backup program (fingers crossed). I plan to add a parser that will backup include files if they have changed.

So, stay tuned!

Cheers!

[keithdoxey]

Hi picnaut,

Thanks for an excellent little utility. Just tried it for the first time and it seems to do just what I want with regard to tracking changes and auto saving.

I use a program called "Beyond Compare" from ScooterSoftware for comparing files which allows me to easily view differences.

With regards to "Version Control" I think a "New Version" should be a manual option but auto backup whilst developing is exactly what is needed. When you get to a stable release then you "publish" a version e.g. "myprog.bas" is the initial file that you work on and that name never changes but gets constantly archived each time you compile.

The version files get saves into a Version directory when you have a working version that you are going to release.

myprog_date_time.bas
myprog_date_time.bas
myprog_date_time.bas
myprog_V1.0.bas
myprog_date_time.bas
myprog_date_time.bas
myprog_V1.1.bas
myprog_date_time.bas
myprog_date_time.bas
myprog_date_time.bas
myprog_date_time.bas
myprog_V2.0.bas

My reasoning behind this is that each time I compile a program, it is not always a version. Once it works as intended it becomes a version. Then the inevitable bug fix becomes the next version but there could be many recompilations between V1.0 and V1.1 as I am sure almost everyone would have experienced.

It would also mean that if V2 had new features that people had to pay for, you could easily go back the latest V1.x and fix a bug without giving away the new features unless they pay for them

Keep up the good work

Regards

[picnaut]

Hi Keith,

I actually worked on the utility for a while last week.
I'm going to write it to ONLY create back up copies when the files actually change. Basically, every time a basic file is compiled, my software will compare it to the last time it was backed up. If it hasn't changed, then it won't back up the file. Also, it will parse the basic file for include files and will look for them to see if they have changed. So, if you only change the include file, it will only back that up. It's starting to get more and more complicated. I plan to release a beta version in the next couple of weeks that will basically only do what it's doing now, but better (I've done a complete overhaul of the program). Also, it will be able to monitor other IDE's as well.

Anyway, I have a busy couple of months ahead of me. I'm going on vacation for 3 weeks in December and I'm busy with work as well. Lunch hours are basically all I have until the middle of January.

Stay tuned!

Cheers.

[keithdoxey]

I actually worked on the utility for a while last week.
I'm going to write it to ONLY create back up copies when the files actually change.

Hi Picnaut,

That sounds great. It would be nice if you could incorporate a manual option to create a named version as well.

Something along the lines of

Click on "Basic Backup" on task bar and when the window appears it has a text box for the version name and a button "Create Version". That way the user is free to number versions how they want to.

eg type in "V3.2.5" and in a versions directory it copies myprog.bas as myprog_V3.2.5.bas

I'm thinking about how it works in Visual Basic etc where you make changes and compile the program to run in the IDE. You save it and come back next day etc but until such time that you choose the "Make Project" option it you dont create the next version/revision.

If the last time you created an exe file it was V3.2.4 then the source code is "V3.2.4+the_changes" until such time as you create a new exe when it is then V3.2.5. The actual source is still called myprog irrespective of the version you are at.

In many respects your program is far better than the way VB does things as you can roll back and undo all the changes that you made this morning before you were properly awake.

Your program is already doing most of that automagically, it would be just perfect if you could create an identifiable build that was of significant importance compared to the many timestamped backups during development.

Hope that makes sense!

Thanks again for an excellent utility that is about to be severely tested as I make major changes to a project that is currently working but desparately needs the code tidied up!

Regards

[picnaut]

Hello,

Well, I've been working on that backup program and I have it working well with "another PIC development environment" but I can't seem to get it to work the way I want to with PBP. Because of the option to use either MPASM or the PM assembler, I need to be able to detect when the PBP.exe (or PBPW.exe) is launched. I have no problem detecting the "other" compiler because a little window pops up to tell me it's compiling. However, the PBP program is a console executable and is proving very troublesome to detect. Luckily, most of my backup program's code is generic. So, as soon as I can figure out a way to detect that the PBP compiler is running, I'm in business.

If anybody knows VB and would like to take a crack at writing a routine to detect whether PBP.exe or PBPW.exe is running, go for it and let me know.
It's my only hurdle right now.

Cheers!