Version Control

[mytekcontrols]

Hi PicNaut,

Well I tried out your backup program, and it did a great job of backing up my main file when I compiled it, but this wasn't the file I had changed. In actuality it was one of the include files that had been updated and saved. For anyone that doesn't use include files, I would say your program would be quite a success. However for someone like myself, where I break down all the various modules into independant include files, the program in its present state would be of little use. Please don't let this discourage you. What I see for a first attempt is very impressive.

I anxiously await the next revision

[picnaut]

Hi Guys,

Thanks for the input.

As for using the PBP compiler instead of MPASM, I'll see what I can do.
I have a work around for that, but I'm not overly comfortable with it, because it involves messing around with a couple of PBP program files.
I'm trying to stay completely hands-off of the compiler and MCSP.

As for the include files, I actually knew about that "flaw" already.
I just don't use "new" include files every time I make a project.
Does everybody else?
Generally, I keep my include files in one location and only change them to improve them (without affecting other code that depends upon them).
I do appreciate why you write your code the way you do though.
Do you keep all of your project's includes in the same folder as your .BAS or .PBP file? If so, 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.

Regards,

[btaylor]

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. During the development of that block of code surely it could have gone through Picnaut's backup process.

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.

A PBP/PM version would be fabulous, even if it worked slightly differently to the MPASM version. I see it as important that the PBP files do not get changed as this could create nightmares with future PBP upgrades.

Cheers
Brian

[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.