Post by thread:[PIC] More CVS for PIC development

I was approached by somebody who asked me how I provided revisions and backed up code since I have gotten out of hardware (I only do PIC firmware, write short stories, and play Texas Hold'em. Only Texas Hold'em makes any money). I wrote a program in DOS several years ago (in the olden days) that provided a simple backup system. Everytime I made a change, I created a ZIP backup of the sources set and the hex output file, and named the output file the project name + ",Z??", where Z?? ranged from Z00 to Z99. Before the latest ZIP was written out, the program renamed all the older backups, tossing Z99 then renaming the old Z98 to new Z99, etc until all were updated. The original time and date of the archive always remained, because I always renamed but never recreated the archive. So the very latest was always named Z00, the next latest Z01, etc.Some projects never took 99 passes so less than 100 archives are kept in tiny files. Presently, I simply ZIP up once a day, but the old way was very accurate, easy to use, and provided a history of the development task. I think I'll breakout Delphi 6 and convert the old Turbo Pascal over to a Windoze version. Why wouldn't that be enough? Flames accepted. --Bob -- Note: To protect our network, attachments must be sent to spam_OUTattachTakeThisOuTengineer.cotse.net . 1-520-850-1673 USA/Canada http://beam.to/azengineer

On 1/18/06, Bob Axtell <.....engineerKILLspam@spam@cotse.net> wrote: {Quote hidden}> I was approached by somebody who asked me how > I provided revisions and backed up code since I have > gotten out of hardware (I only do PIC firmware, write > short stories, and play Texas Hold'em. Only Texas Hold'em > makes any money). > > I wrote a program in DOS several years ago (in the > olden days) that provided a simple backup system. > Everytime I made a change, I created a ZIP backup > of the sources set and the hex output file, and named > the output file the project name + ",Z??", where > Z?? ranged from Z00 to Z99. Before the latest ZIP was > written out, the program renamed all the older backups, > tossing Z99 then renaming the old Z98 to new Z99, etc > until all were updated. The original time and date of the > archive always remained, because I always renamed > but never recreated the archive. So the very latest was > always named Z00, the next latest Z01, etc.Some projects > never took 99 passes so less than 100 archives are kept > in tiny files. > > Presently, I simply ZIP up once a day, but the old way > was very accurate, easy to use, and provided a history > of the development task. > > I think I'll breakout Delphi 6 and convert the old Turbo > Pascal over to a Windoze version. > > Why wouldn't that be enough? Flames accepted. > > --Bob > It sounds like you've reinvented RCS. :) Actually, I think a script like yours was how RCS got started. I think your system works well for you. Assuming you don't have multiple personalities, concurrency management won't be a problem. In fact I used to use a system very much like yours (where my names were like projname-0.1.0.tar.gz, projname-0.1.1.tar.gz etc.). However, there are features that make a system like Subversion more desireable. When you commit changes, you are invited to attach a comment explaining the commit. Later, these comments are very helpful if you want to go back and see where you screwed up. Also, I recommend installing ViewCVS (recent versions also work with SVN), which is a cgi script that makes a hyperlinked, annotated code listing and makes navigating through different versions very easy. You may have used it before at sourceforge.net. You could approximate all of these capabilities with a properly-maintained text file listing revisions and judicious use of 'diff', but I find it easier to just use Subversion and ViewCVS and spend my creative energies on writing firmware. It only takes half a day to set up Subversion (assuming a modern Linux distribution) and another half day to learn to use it. I consider it time well spent. There are also advantages if you do your development on more than one computer, especially if one of those computers is a laptop. Regards, Mark markrages@gmail -- You think that it is a secret, but it never has been one. - fortune cookie

Bob Axtell wrote: > Everytime I made a change, I created a ZIP backup [...] > Why wouldn't that be enough? Flames accepted. Compared to Subversion? All the same data is there, but it gives you a convenient way to: - See the diffs between any two revisions. This is often useful for asking questions like "I screwed up - what have I changed since the last check-in?" or "When did this bit of code go in?" - Keep a description of why you made each change. Useful for answering questions like "What was I thinking when this bit of code went in?" - For multiple developer projects, answer "Who changed this?" and also make it clear which version is the authoritative one. And, make it easy to update my code with your changes without disturbing the changes I've made in the meantime. - Manage code branches, and merging a branch back into the main line. There are more, but those are the main ones that matter to me. -- Timothy J. Weber http://timothyweber.org

On Jan 18, 2006, at 4:43 AM, Bob Axtell wrote: > Why wouldn't that be enough? The need for revision control changes as the size and complexity of a company changes. What you were doing (backups for every change) works fine for a single person and well-defined separated projects. Something like RCS is probably sufficient for small groups of engineers and larger projects, with the main add-on feature being well-NAMED edits. CVS works better for larger numbers of engineers working on the same code base. Something like clearcase seems to be needed for very large source repositories and larger numbers of engineers (a somewhat controversial subject here.) BillW

Timothy Weber wrote: {Quote hidden}>Bob Axtell wrote: > > >>Everytime I made a change, I created a ZIP backup >> >> >[...] > > >>Why wouldn't that be enough? Flames accepted. >> >> > >Compared to Subversion? All the same data is there, but it gives you a >convenient way to: > >- See the diffs between any two revisions. This is often useful for >asking questions like "I screwed up - what have I changed since the last >check-in?" or "When did this bit of code go in?" > >- Keep a description of why you made each change. Useful for answering >questions like "What was I thinking when this bit of code went in?" > >- For multiple developer projects, answer "Who changed this?" and also >make it clear which version is the authoritative one. And, make it easy >to update my code with your changes without disturbing the changes I've >made in the meantime. > >- Manage code branches, and merging a branch back into the main line. > >There are more, but those are the main ones that matter to me. > > Oh, of course, I owned a manual file comparer as well. Well I was basically a one-man band as far as firmware was concerned... --Bob -- Note: To protect our network, attachments must be sent to attachKILLspamengineer.cotse.net . 1-520-850-1673 USA/Canada http://beam.to/azengineer