Version Control - AUTOMATED
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.
No use re-inventing the wheel...
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.
Here is a freebie called CS-RSC
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.
3 Attachment(s)
CS-RCS Version Control Software Update
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:
Quote:
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
How many ways can you peel an orange?
Hello Picnaut, Darrel, Brian, and Sougata!
Quote:
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).
Please participate in my poll
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!
Tested Beta Version Control
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 :)
The INCLUDE flaw is no flaw to me
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
Trouble detecting console executables
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!