Version Control

[btaylor]

I am having trouble with tracking changes. Most times I get it right by re-naming the file in MCSP before I compile but occasionally I forget, make changes in the code and then find it no longer runs.

What I would love to see is MCSP automatically increment the file name every time it compiles.

Something like
myfile000.pbp automatically becomes myfile001.pbp when I compile. That way I can always go back to the previous version.

Yes this will eat disk space but is a small price to pay.

What are other PBP users using for Version Control?

Cheers
Brian

[Melanie]

Very simply...

aaaa-bc.bas

where 'aaaa' is the Project Code
'b' is the PCB Revision
'c' is the Software Revision

example...

9912-2F.bas - Project 9912, PCB Version 2, Software Version F.

The software ending with the highest letter of the alphabet is always the one that is used for current production burn.

Remember to document your changes in comments in your program header. In six months time you'd have forgotten what you did and why.

[picnaut]

Hi Melanie,

That's a good idea including the hardware version number in the software file name.
I include it in e-squared on the device as well.
If I need to upgrade firmware, my software checks to see if the hardware is up to date enough to allow the latest firmware upgrade.

Regards.

[btaylor]

Perhaps I was not explicit enough. I already make the very first line of all my programs a DATA statement which writes the program name and version off to EEROM. Later in my program, I always have a read block that shows the version details as a serial data stream.

What I am searching for is something that automatically increments the file name EVERY time a compile is done. Occasionally I find I make a 'minor' change, forget to update the file name or version, then find unexpected things got clobbered.

Personal discipline should mean I never make that mistake but it still happens.

I guess this is really a plea to David Barker for an enhancement to MCSP.

[mytekcontrols]

I also use MicroStudio, and would love it if it had an option to auto save numbered back-up files upon a save or re-compile. Not having this, like you said, can really mess you up if you forgot to do a manual back-up yourself (something that can bite even the most diligent person). I'll have to take a look on the net to see if there is a 3rd party back-up system that would be suitable.

[picnaut]

Hello,

If you can program a PC, there are a lot of resources on the net.
I've gathered together a number of tools that would make a 3rd party version of this very feasible. I don't have time to work on it now, but maybe in the next week or so. Basically, you could leave MCSP totally out of the loop here. The program I would write would launch when windows started and run in the background, hardly using any resources. It would look for "PBP.exe" to be run. As soon as PBP.exe closed, the program would make a copy of the .BAS (or .PBP) file and add an incremented number. A dirt simple version of this, that is tailored to one project (with an .ini file), could probably be whipped up quickly. A more complex version that monitored what files were passed to PBP.exe and was not souce file specific would involve a little more work.

Unfortunately I'm really busy from now until the New Year with work and wedding preparations. However, I am going on a business trip in mid-November. I may have some time on the plane to whip this up. Maybe even before then. I don't know.

Anybody...feel free to beat me to it.

Cheers.

[mytekcontrols]

Hello Picnaut,

It is very generous of you to offer to do this, but I can't help but feel that there is already a solution out there. I did some initial checking today and discovered a multitude of programs that offer selective file back-up, and some apparently with either version number and/or date archiving. Most also offered the ability to only back-up on change, which would be most desirable. Of course some of these packages are quite expensive, whereas others are very cheap if not free. I'll be checking this out in more details in the days to come, and post my results here.

[mytekcontrols]

I found this one today and have installed it as the single-user freeware version.
http://www.componentsoftware.com/Pro...S/freeware.htm

It is a bit sophisticated, but offers a very robust method of software Version Control, that works on the check-in and check-out basis. Everytime you check-in a file or an entire project folder, a new revision level is assigned in the archival storage folder. Checking-out updates the working file or folder to the latest checked-in version. You can also add comments for each check-in, which can be seen by right clicking a given file, and selecting history, which will then give you a list of every revision. There is also a feature that will show you the actual line changes within the file in a very visual and intuitive way. This program has a lot to offer, but it might be way more then some are looking for.

So far I like what I see.

[mytekcontrols]

Well I've been actively using this software for a few days now, and I must say I am very impressed, and pleased with how it works.

Brian you stated:

What I am searching for is something that automatically increments the file name EVERY time a compile is done. Occasionally I find I make a 'minor' change, forget to update the file name or version, then find unexpected things got clobbered.

It doesn't quite work as you have outlined above, but I think the CS-RCS approach might still satisfy the essence of what you are looking for... namely, a way to recover from unexpected problems due to minor changes. The difference is that you have to manage the process.

Here's an overview on using CS-RSC:

The best way to use it, especially for people like me that use multiple include files, is to define a project folder and move all your working files into it. This is done by using the CS-RCS Properties part of the program (I wont get into this too much here, because it is well covered in the help file).

Once a project has been set-up and all the working folders are checked-in, the Document Explorer will now become your management tool for these files.
<div style="float:left; padding-left: 225px;"><b>Document Explorer</b></div>
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=587&stc=1&d=1130783295 " style="clear: left;float: left; padding: 8px;">
From this window (available on desktop) you can see any files that have changed within the project being highlighted in blue, and unchanged as black (changed files are files that have been modified and saved).

To the far right is the version number assigned to the file the last time it was checked-in. Right click any file To obtain the Status, to Check-it-In, to Check-it-Out, to see the History of changes made, ect.

The RCS Status option is rather cool. It allows you to open a "Differences" window that lets you see the actually changes that have occured to file. In the example below, can be seen the line-by-line modifications, with deletions shown as crossed out red colored text. And stuff that was added, is shown in blue text.


<div style="float:right; padding-right: 200px;"><b>Differences Window</b></div>
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=588&stc=1&d=1130783295 " style="clear: right;float:right; padding: 8px;">To review all the changes, you can use the arrow keys to step yourself through everything that is different from when the file was last checked-in.

To make this system really work well for you. It is important that you check-in files when you feel that you are at a stable or working version. Remember to do this before you go on to make additional changes, or to try out some new hack. This way if the changes really mess something up as Brian pointed out, you can always use the check-out feature to restore the file back to the last checked-in version. To help you analyze the multitude of checked-in versions that will inevitably accumulate, a note may be added to describe it, which can be seen by mousing over the file name (also available in the Revision Manager Window).

!!! IMPORTANT !!!
Only use check-out when you are certain that you no longer want the present un-checked in state of the file (the present working copy). Checking-out will over write it. If you are unsure about this, it is best to check-in the file, since you can always pull up a copy of any checked-in file you want.


<div style="float:left; padding-left: 225px;"><b>Revision Manager</b></div>
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=586&stc=1&d=1130780524 " style="clear: left;float: left; padding: 8px;">
The Revision History option available from the right-click menu, opens up the Revision Manager. This is where you can review all the versions that were checked-in, see the notes on the changes that were made, and retrieve a copy of any previous version (an actual copy is made into the Project folder --- it does not over write the current version).

Milestones:
Sometimes it is desirable to mark a certain revision level as having some significance, or having achieved a milestone (i.e.; "released beta version", "production release", ect.). Using the Milestones feature from the Document Explorer menu, allows you to do this very thing. Milestones can also be retrieved, similar to the way the Revision Manager retrieves previously checked-in versions. I wont get into all the details about this feature, but it definately can help add another layer of organization to your project.

Well hopefully this gives you a good quick glance of the CS-RCS system, and also what it can do for you. Remember this tool is not just limited to use with your PBP source files, it could also give you version control of any other documention that you may have a need to track changes on.

And last, but not least, NO I am not affiliated with or get paid by Component Software the makers of the CS-RCS program I have described. I just like what I see, and I think it can be a great companion to PBP and/or MicroCode Studio.

(thank you Brian for starting this post, and opening my eyes

[sougata]

Hi,

Thanks for the good job. It is really great.

Regards

Sougata

[picnaut]

Hi Guys,

I'm working on something that's PBP specific and it's going to be great (if I can find time to do it).

On my lunch hour I whipped up a little application that is able to extract the name and file path of the .BAS (or .PBP) file that is passed to the compiler by Microcode Studio.

Basically, I created and executable called "PBPW.exe".
I then renamed the "PBPW.exe" in the PBP folder to "PBPW_Real.exe".
Then, when you compile, "my" PBPW.exe is launched.
All my program does is grab the parameters (which includes the file name and file path of the source code) and then launches "PBPW_Real.exe" (which is the authentic PBPW.exe).

That's the hardest part. The rest is easy.
I think what I'll do with my program is get it to make a copy of the source code and slap on a date and time stamp.
It will then put it in a folder called "PROGRAMNAME_Backup" (PROGRAMNAME being the actual name of the source code).
It will create the folder if it doesn't already exist.

Alternatively, I could configure it to place all backups in a central location but grouped into their respective "PROGRAMNAME_Backup" folders (as mentioned above).

If anybody else has some ideas about this, let me know.

If think it would be really cool because you wouldn't even need to configure it.
It would just run each time the compiler was run and continually create backups at each compile.

Cheers!

[Darrel Taylor]

That would be a great addition!

Anyway you can do that comparison highlighting? so you can tell what the differences are between the versions. Having 40 or 50 backup files in a folder will make it hard to tell what the changes were, and when they were made. And, if you revert back to an older file, how many recent changes will you lose.

Sometimes, just seeing what you changed will remind you enough to fix the problem, without having to revert to a previous version.
<br>

[btaylor]

I think Picnaut is on the right track here.

I have used a system similar to the checkin/checkout version control systems proposed by Michael St. Pierre before but they need personal discipline to make sure every change gets checked back in then out again so it gets its own version. For example you can check out a working version, spend days making many revisions (but not checking the file back) and then crash and lose several days work. The CVS has the 'official' version of days ago and all the subsequent steps are lost.

What I need is an AUTOMATED way of making a separately named backup EVERY time a compile is done. That way there is always a short path back to the previous state. Picnaut seems to be near to this.

I don't think it needs to highlight what the changes were, I usually write in the comments at the top of the file what I am attempting with each version. Yes there will be massive file expansion but these can be easily cleaned up at the end of the development session.

Keep it up Picnaut!!

Cheers
Brian

[mytekcontrols]

Hello Picnaut, Darrel, Brian, and Sougata!

On my lunch hour I whipped up a little application that is able to extract the name and file path of the .BAS (or .PBP) file that is passed to the compiler by Microcode Studio.

Sigh... If only my lunch hours proved as fruitfull <img src="http://www.picbasic.co.uk/forum/images/icons/icon7.gif">

If Picnaut is willing to do it. Then I'll certainly give it a whirl. I like keeping things backed-up in multiple ways, so having Picnaut's application running along side the version control system works for me. Like Brian, I've used Version Control systems at places I've worked for, so I'm rather used to using them. And by having to make it a habit, I have no problem keeping things up-to-date. However, I also run an automatic back-up app in the background, which insures that I always have a copy of my work that is no older then about 10 minutes. It doesn't do version control, but it only backs-up something that has actually changed, thereby not consuming much processing power or time.

Each method has its own benefits or strong points. It would be nice to have everything in one package, but then look what we do with PicBasic. We add some assembly code snippets, and some macros, all in an effort to make the best of all worlds.

Hey Picnaut, if you don't mind me asking, what kind of work do you do for a living? It sounds like you are very well versed in the programming world.

Oh and before I forget. Thank you Sougata for your kind words. It is appreciatted. It was rather interesting to figure out how to post the info, so that I could get the layout that was as presented (I'm sure Darrel can appreciate this aspect).

[Darrel Taylor]

Yes I can. And I must say, that's the best looking post I've seen around here. The images offset to either side, and the way the text flowed around them, very nice. You have definately "raised the bar". Which of course means, I'll have to jump over it.
<br>

[picnaut]

What I need is an AUTOMATED way of making a separately named backup EVERY time a compile is done. That way there is always a short path back to the previous state. Picnaut seems to be near to this.

Yep!

I've actually totally changed my approach.
The program I have now simply runs in the background and checks every half second to see if something is being compiled. If it is, then the .BAS file or .PBP file get's saved in the associated backup folder with a date and time stamp as part of the file name.

There will be absolutely no interfering with the PBP software files.

I'm going to limit configuring options at first, but it will be really easy to use.

With the executable file (which I hope to attach in the next day or two) you will only have to launch it once, and then it will run every time you start Windows. It will truly be set and forget software.

Stay tuned!

[picnaut]

Hey Picnaut, if you don't mind me asking, what kind of work do you do for a living? It sounds like you are very well versed in the programming world.

Hi,

In regards to your question, I'm a hardware engineer.
I'm actually just about to jump feet first into PCB layout. I'm taking a course in Philly in November.

As for programming, from October 2001 to November 2004 I wrote automated test apps. That was a lot of fun! I got to write PC software that interfaced to a lot of other equipment (including PICs). I was able to do some embedded with that as well.

Eventually I want to work for myself full-time, but that's a little way off yet. I need to get my skill set stronger. Currently, I'm reasonably good at several things, but, unfortunately, not great at any one thing.

I see you're in California. I'm just north of the US border in Vancouver, BC, Canada.

Anyway, take it easy and keep on Pic'n!

[mytekcontrols]

Yes I can. And I must say, that's the best looking post I've seen around here. The images offset to either side, and the way the text flowed around them, very nice. You have definately "raised the bar". Which of course means, I'll have to jump over it.

Darrel,
I think you already jumped over it with some of your posts, like the LCD character generator for instance. But you did give me an idea. The only problem will be finding time to do it. Wouldn't it be cool to have a WYSIWG offline program tailored to this forum that would make creating better layouts an easy job, and not an exercise in embedding html and css via the text only editor provided. Something to think about <img src="http://www.picbasic.co.uk/forum/images/icons/icon12.gif">.

[picnaut]

Hello,

If you haven't done so already, could you please participate in the following poll: http://www.picbasic.co.uk/forum/showthread.php?t=2694

I've got the compile-detect and source-filepath-extraction portion of my program running well now. However, it only works when the compiler uses MPASM as its assembler. Also, if I hadn't mentioned before, it requires Microcode Studio to be running (you can't just compile from the command line).

Anyway, I'm getting closer.

Cheers!

[picnaut]

OK.
I'm almost there.
I have a functional program that's working great.
Unfortunately, you must be using MPASM as your assembler to use my auto updating program. Also, you need to be using MicroCode Studio Plus as your IDE (I may add support for other IDE's later).

I'm calling it "Basic Backup" and I should have a beta version out later tonight or tomorrow.

The only thing that you need to do before you use it, is check the box beside "Display full filename path in application title bar" in MicroCode Studio Plus. See: View > Editor Options... > General (tab)

Then, if all goes well, you will only need to launch the "Basic Backup" executable once and it will launch each time you start Windows.

Wish me luck!

[picnaut]

Hello,

Try this out and tell me what you think.

It's got some minor bugs and needs work still, but it is functional.
Simply start it up when you want to start coding.
You can put a shortcut to it in your Windows Startup folder then you don't have to worry about it.
I'll keep giving each executable the same filename so you can simply swap it out.
You shouldn't need an install package.
Simply unzip it and run the executable inside.
It will run in the background and backup all your PBP files each time they're compiled.

Make sure that you set your IDE to display the full filename in the application title bar (editor options).

Also, it will ONLY work if you are using MPASM as your assembler.

If you see any bugs, let me know and include any pertinent information (i.e. your operating system, memory, CPU speed, MCSP version, etc.).

You may need to get the latest VB6 Runtime files.
They can be downloaded from:
http://download.microsoft.com/downlo...vbrun60sp5.exe

However, don't download and install them if you've already tried the "Basic Backup" program and confirmed that it works. It would be handy to know if the runtime files are required or not.

Cheers!

[btaylor]

Thanks Picnaut.

The concept sounds great. I downloaded, unzipped and installed. It all ran with no drama on a Toshiba TECRA laptop with WinXP pro on it. I don't know if it has the latest VB nonsense on it.

I was not using MPASM and so I had to download it, unzip it and tell MicroCode Studio Plus to use MPASM - a few clicks.

Now the hard part. Programs which previously compiled and ran fine crash at compile time with a heap of MPASM error messages.

@ DEVICE PIC16F876A, HS_OSC, etc gives me an 'unknown processor' (16F876A) message.

Cannot find PIC16F876.inc , trisc not previously defined, etc, etc. The error list takes pages and pages.

A previously working PBP program that generates code of 2512 words using the PBP default assembler fails to compile and generates 3444 errors when using MPASM as the assembler.

I checked the program directory and there is a new subdirectory. In it is a file with _051103_094849 appended. Your program certainly seems to work as advertised and might eventually solve my backup problems.

Unfortunately I am up against a deadline so I'm going back to the tried and true (PBP assembler) to finish this job. I hope to get back on this early next week.

If you could make your program compatible with the PBP default assembler that would be fabulous. In the meantime I have to find the time to learn how to drive MPASM.


Thanks again

Brian

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

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

[picnaut]

Hello Everyone,

Well, I've finally done it, thanks to some help from Nuno.

I've created a backup program that works with both PBP (running MCSP) and with Crownhill's PDS. I will try to add additional IDE support in the future.

It will backup source code whether it's compiled with MPASM or the PBP assembler.

You must have PBP installed in the default filepath though (c:\pbp\).

Unfortunately, it doesn't backup include files at this time.

However, I've been told that if you try and compile an include file on it's own, it will get backed up, even though the compile operation fails. I'm not sure if that's a bug or a feature.



In any case, unless you're using include files that you plan on changing, this should work just fine.

I will add a parser in the new year that will look for all of the includes in your "main" .BAS file and back them up when they've changed.

Until then though, I'm off to the sunny Caribbean for 3 weeks of relaxation. So, no tech support until January 10th, ok.

Have a great holiday everyone!

Regards,

[boroko]

Hi all,
Along the lines of this thread, I wondered how you folks deal with deleting the many unneeded previous versions ( and specifically all of the compiler and extra files) after you have a set of workable ones?

I usually have a few revs that I want to save and go back to, but all of these previous development files become burdensome after a while. You can delete the .PBP files pretty easily, but to get rid of the trash, I have to open the whole folder pick and choose.

I wonder if there is a way to accomplish dumping the whole set of files associated with a certain rev without doing it in such a tedious manner?
Say an option in MCS that allows you to delete the main file and it automatically grabs the support files and dumps those too. If I delete the .PBP files, I leave a bunch of orphans (.asm, .cod, .hex, .lst, .mac).
Doing it manually takes quite a bit of concentration and time.

I suppose one way would be to delete ALL of the support files and then remove the .PBP files that you don't want. You would then have to re-compile the ones that you have left when needed.

Just looking for thoughts
Bo

[mackrackit]

On larger projects I end up with multiple directories and sub dirs.TestWorkingRevFinishThe names are self explanatory.When I have something in the Working directory that works I complie and save to a Rev dir. When things get to the Finish I just delete the dirs not needed.