"Source code control" or "vesion management" is a procedure for keeping track of all the changes to a piece of software source code. Of course we have programs to help with this.
In the simplest case it helps you keep track of what your state your code is in. I bet you have found yourself keeping old revisions of code as you work. You know, in case your latest modification turns out to be a mistake and you want to go back to an older version. Or perhaps you want to try some experiments on your code so you copy the whole project to another directory and work on changes there. Meanwhile the original directory might still be worked on as it is the one that works. Very soon you find you have a whole hardrive full of different versions, different branches with different features and backups all over the place and before long you have no idea what is what.
A version management tool will keep a data base containing all your code. When you add changes to the code you can leave little notes attached to the change to remind you what happened. You can tag or name significant versions that work as you like. Such a tool will help you keep track of different experimental branches and help merge the experimental changes into he main branch of development when you are happy with them.
All these problems get much worse if you have a lot of code in a project and more than one person working on it. But such a version control system is briliant even when working alone.
There are many version control systems, Subversion, CVS, git, MicroSoft Visual Source Safe etc etc.
I would suggest looking at www.github.com. They use the git system as used for Linux. You keep all your code on a repository (database) on their servers, no worries there you have an exact clone of the repository on you machine as well. Git hub also keeps a wiki along with your project for all those design notes to your self and there is an issue tracking system that you can use for reporting bugs or feature requests to yourself.
Having been a teacher, on ise soon discovers that the mystery how to sustain motivations.
You might try listing ambitions, motives, and benefits to see how a project fits in on a sustainable basis.
If you are trying to motivate others, you might trying to figure out if they are ambitious, greedy, and hungry. It really takes all three to really drive a project forward.
I realize this is a rather Machiavellian approach to the problem, but I rarely get much done as I am not ambitious, greedy, and hungry... whereas the pundits of success, Bill Gates, Steve Jobs, and that Facebook whatshisname nicely demonstrate the model.
These days a personal review of my ambitions, motives, and the benefits I seek nicely define the kind of person I want to be. I can accept that. But in earlier years, there were a lot of conflicted items and turmoil in wanting what was not to be or what was beyond my desire to reach far enough.
Sure, you can take a sterile approach and say it is all organization, administration, and time management.. but people come and go for the oddest of reasons. The ones that stay with a project are getting the most of what they want with this project regardless of what they say or how they pose themselves.
A problem I deal with as well. Besides the robots, there are a number of experiments with LEDs and lasers, gyros, accelerometers and GPS. Building a PIC project board and audio amp. Building another OWI robot arm to be uP controlled. Learning to program an SX Tech board to run one of the 'bots and still learning the Prop and Spin. And that's just most of the electronics hobby stuff. Then there are the telescopes, SW radios and computers. I should post a picture of my desk someday!
When I run into any sort of "hiccup" on a project, I jump into something else till an answer comes along. Though with so many things going on, it takes "forever" to get back to a specific task. :-|
Perhaps it would help if there were some sort of =real= deadline, but it's just me and no one cares! :-)
Amanda - The important thing to me is... it's all fun!
1) Software: I have a synchronized folder structure that is routinely backed up for all softcopy items. My folders are Books, Code, Projects, Software, and Specs. Everything I do in my hobby is in one of those folders and each has it's own set of subfolders, depending on it's complexity. In my projects folder, I currently have 73 subfolders (main projects)
2) Hardware: I keep everything organized in various sizes of "Really Useful Boxes" and nab new ones every time Staples runs them at 40% off. I try to keep larger projects in their own box of an appropriate size. I also have 6 large totes for those long term projects and 2 Grab-n-Go organizers.
3) Organization: Let me know if you find something that works. I have struggled for about 2 years trying to organize my projects. I did use a Google site to kick off my last Propeller module and it worked very well, using the project wiki template. It took a bit of playing around to learn how Google Sites worked, but I love it and use them all the time for project management at work since we use everything Google. Google Sites easily integrates Google Spreadsheets, GMail, and other features quite nicely.
"...I bet you have found yourself keeping old revisions of code as you work. You know, in case your latest modification turns out to be a mistake and you want to go back to an older version. Or perhaps you want to try some experiments on your code so you copy the whole project to another directory and work on changes there. Meanwhile the original directory might still be worked on as it is the one that works. Very soon you find you have a whole hardrive full of different versions, different branches with different features and backups all over the place and before long you have no idea what is what...
You've nailed it. I name my code "V1", "V2"..ect and make notes in the CON block listing what each does. My methods do not address 'parent/child' code hierachy among other things. I will follow the advice in this thread.
You've nailed it. I name my code "V1", "V2"..ect and make notes in the CON block listing what each does. My methods do not address 'parent/child' code hierachy among other things. I will follow the advice in this thread.
I think version numbers are helpful but I don't think they are adequate for keeping track of program versions. I don't know about the rest of you but have usually end up with scores of versions of code. Keeping track of what child version goes with which parent can get a bit hairy.
Here's my method of trying to keep software versions straight. I add a date stamp to the name of the program with a version letter. I also include this name in a DAT section at the top of the program. Here's an example of the beginning of one of my programs:
DAT programName byte "DemoFourMotorsAndEncoders130215c", 0
CON
{{
******* Public Notes *******
}}
{
******* Private Notes *******
130125a Use debug statements in parent object
instead of child object.
DemoFourMotorsAndEncoders130125a modified from
DemoFourMotors130125a.
DemoFourMotorsAndEncoders130125a add encoders.
31c Comment out motor control.
I often don't fill out the "Public Notes" section until I'm ready to post the code to the forum or OBEX. I usually just note the day of month and version letter when making "Private Notes". If it's been a while since I've made changes, I include the full date stamp. I also note when I change the name of the program.
The first line has the 'programName" string. I usually have this string displayed (if there is a display) when the program first starts up. This helps me know which version of the code is currently running on the Propeller.
It also helps to keep track of which child object was being used at the time. Here's the OBJ section of this example.
By having the version information in the program name, it's much easier to keep track of which parent object used which child object.
This may seem pedantic but I have found it to be very useful.
For those how may not think this is pedantic, just wait, it gets worse better.
I often want to have the names of the child objects displayed so I include methods like these in the child objects.
PUB GetFileName
'' This method returns the name of this object.
'' This method is not needed for proper operation of object
'' and may be deleted.
result := @programName
PUB GetPwmGrandChildName
'' This method returns the name of this object.
'' This method is not needed for proper operation of object
'' and may be deleted.
result := Pwm.GetFileName
PUB GetEncoderGrandChildName
'' This method returns the name of this object.
'' This method is not needed for proper operation of object
'' and may be deleted.
result := Encoders.GetFileName
I have a feeling I'm going about this the hard way. I bet the version control software others have mentioned would keep track of this stuff for me if I were inclined to learn to use it. I don't know enough about version control to know what I'd have to gain by taking the time to learn to use it.
I'd be interested to know if one of the version control services is a better fit for Propeller programs than another. If I'm going to learn to use version control, I'd rather just learn one version of it.
Someone here on the forum (I think it was Roy Eltham) suggested using DropBox to make sharing files between computers easier. I liked DropBox so much, I moved all my Spin code into the DropBox. Now I can access the latest version of my Propeller programs from any of the computers I use.
If any of you haven't tried DropBox, use this link so we can both get an extra 500MB of free storage.
Now I just need to finish the robot to put away my stuff (and retrieve a cold beverage from the frig).
On the versioning comments, yes, it is an excellent way to keep track of your code status. I rename and save my SPIN files with any significant change. For my Reverse GeoCache project, I detailed each version and it was the 16th version that was posted as final. Here's an example:
DEVELOPMENT VERSIONING
000 - Started with Google Earth KML Logger. Modified pin assignments for my demo board setup (currently no switch, assigned to unused pin)
001 - Added LED2 for "is Longitude > 99" status check
002 - changed atoi string from 3 to 4
003 - Added multiple longitude routines for debugging
004 - Modified longitude routines for debugging
005 - Removed extra longitude routines, kept working one
006 - Resequenced longitude and latitude routines
007 - Resequenced longitude and latitude routines, updated header and footer in fake dat section, added switch at P0
P08 - Moved to PPDB, added uOLED, stripped down code
P09 - Modified display features
P10 - Added Servo functions
P11 - Added Matching routine to Longitude (green value means match) and SW01 unlock bypass routine
P12 - Added Matching routine to Latitude, minor housekeeping, set lat/lon to Parallax, LED2 commented out
U14 - Moved to USB Protoboard, changed pinouts
U15 - This was the "5:15am on birthday morning but it works!" version. (12/21/09)
U16 - Final clean up/commenting for posting on completed projects forum. (1/1/10)
Write a feature specification at the outset.
Keep a TODO list - this helps tremendously.
Set goals and rewards to help stay on track.
Use a source control system even if you're the only developer.
Don't read the forums until you've achieved something useful.
I find version numbers to be more trouble than they are worth for software.
@jazzed
Interesting observation about version numbers. Some people seem to never get the software to 1.0 even though it is quite stable and useful, others dramatically jump up in numbers and confound the users with hyperbole of the newest is the best.
Linux recently went from 2.6 to 3.0 for the sake of promoting a new era of stability, but I doubt many really understood. Meanwhile the boot loader for Linux, called Grub hung on to 0.99 forever and suddenly created Grub2, and then renamed Grub2 to be Grub 1.99.
The real key here is a real revision control system that allows you to progress AND to have forks if you choose to wander. An online archive is likely more useful for this that a complete DIY set up. You have the opportunity to share and collaborate if you desire.
I agree with Jazzed, for the developer version numbers are just about meaningless.
As you run around the edit, compile, test loop you can have a dozen variations of code per day, or hour depending on your style.
Then what you are hacking today may be an experimental new feature in a branch of the code, so it's versions are totally unconnected with that of the main branch.
You may have many branches at once as you tackle different features or bug fixes.
Then on bigger projects there may be multiple developers all with their own branches and "micro versions".
Enter something like git which does not care about versions so much, It cares about content and changes. You may not commit every little edit you make in a day but you may find you make a commit every time you are satisfied with some feature. That can still be multilple times per day. Same for your collaborators. Every one of those commits is tracked by git not as a vesion number but as an SHA1 hash of the differences that you have made between the last commit and the one before it.
So in git the developers need not think about version numbers, git effectively does that for you.
No, version numbers are for the users of your code. At some point you release something to the world and people use it. As you progress you release new and hopefully better versions. But it can happen that your new version introduces a bug or is some how incompatible with the older versions. Say you have changed a config file format or names of commands etc. Well then the users cannot take that new version into use until they have tweaked their system to accomodate it. They will still want the older version for a while at least.
Users need version numbers so that they can be sure to get hold a version of the code that works for them.
To satisfy that user problem developers should put version tags on their released code:
$ git tag -a v1.2 -m "Version 1.2 release"
I said "something like git". I'm beginning to think there is nothing else like git. It's the best version control system I have ever used. Even if it does take a bit of getting used to.
It looks like "Git" is worth a try. This thread has been helpful. When I start a project it branches off in a hundred directions.The issue of organizational chaos is the same with my other two hobbies. A thread like this is as effective as the journal I used to keep. Progress came from looking at my idle thoughts and thinking them through. In this case a group of people speeds up the thought process.
I suggest you have a look at github.com. As I said if you put your project with them you get a wiki to go with it for project design, usage and other notes. And you get an issue tracker where you can record all your unimplemented features as bugs that need fixing:)
Git is a bit tough to get started with if you have been using other version control systems for a long while. "What two people can be changing the same file at the same time! How can that work out?"
You don't have to be online all the time to use it because basically you have a clone of the repository on your local machine. Just make your edits, commit the changes to your local repo and then push them to github when you want. That also means that if github disappears one day you still have the exact same source and change history locally and can migrate elsewhere if need be.
Downside with github is that if you use their free repository service then it is open for the world to read and download. If you want private repositories it costs a few dollars a month.
In my current idealization of "organized" my hard drive would have nothing on it except when I want to work on it or use it. Like having a cleared desktop. All my little projects would be neatly filed away in github and backed up elsewhere in the cloud just in case.
In your opinion, would the effort needed to learn to use Github be worth the benefits for a single developer of Propeller (Spin/PASM) only software?
Yes, yes and yes. Many lone developers even on small projects have expressed the opinion that using version control has helped them. It gives you great piece of mind that everything is in order and you entire projects history is recorded so that you can always recover any damage you do. No faffing about with billions of different versions of the same files and not remembering which one went with which.
Git can be daunting but the normal work flow is very simple. There are now some nice GUI tools to help if you need and there are lots of tutorials around. Github itself as some good stuff.
You can look at it like this: There is no such thing as a single developer of a project that takes more than five minutes to complete. If you leave your project for a day, a week or a month when you get back to it you may not remember where you were or why. In a way you are not the same developer that left it last.
Have you ever found your self thinking "What idiot wrote this code?" whilst reading some code you wrote yourself!:)
If so you need version control and change history.
I can see this thread has 2 topics in a way..... Physical storage and electronic storage .....
the latter is One I have dealt with ..... but the former is not as easy ........Esp considering many of my projrcts are not one size ........
Ah yes, not sure what to make of the physical stuff, components, chassis, billions of tiny bits that always seem to get lost.
I took this thread to be more psychological than practical. As in the phrase "back in the groove". Staying in the "groove" is a lot psychological but making the practical stuff, both software and hardware organization, easier can help a lot.
Ah yes, not sure what to make of the physical stuff, components, chassis, billions of tiny bits that always seem to get lost.
I took this thread to be more psychological than practical. As in the phrase "back in the groove". Staying in the "groove" is a lot psychological but making the practical stuff, both software and hardware organization, easier can help a lot.
I was mostly referring to the IP aspect, things that can be handled with notes, drawings, etc., either on paper or electronic.
The physical aspect is important as well, so both are on topic as far as I'm concerned.
Of course all the design files for schematics and PCB layouts and mechanical design can also be included in the projects git repository where they will be taken care of along with all your source code. Git can handle binary files but you might want to read up on that if those files are getting very big.
That way you now know that your code and schematics work together when you check out the last know good tested version.
I was referring to PCBs needing some version number when someone else makes the board. I can't imagine spending more than a few seconds trying to figure out what the version is of some project board just laying around on my desk or worse in the old projects box.
I put yyyymmdd-hhmm as a date stamp on everything. From that I know pretty much how long a thing is expected to last, whether it might be broken, and if its the one I'm looking for. In the case of files, I end up with a lot of old versions, but disk space is cheap, and I nearly always can go back and retrace my steps if I need to.
The other thing is asking "is this important to my main goal" and put stuff away if its not the critical path. Actually, I have a big shop and don't have to put stuff away for a long time, and stuff tends to get buried and lost, but you get the idea.
The last thing is notes, as other folks have said. I know when I read my notes I will have forgotten everything about the project, so I put enough detail so a n00b can produce the correct result.
Lots of interesting ideas here. The worst thing is when several projects are completed under a deadline and the documentation of firmware and hardware gets shoved to a back burner.
Each project gets its own folder including any modified library objects, and each deployed release gets zipped into a dated file. Always keep a working prototype of any device developed or sold to anyone else. Has to be included in the cost of business.
When Gareth was asking about the line algorithm, I recalled a piece of hardware I made to draw cycloids on an X-Y display of an oscilloscope for a science exhibit. I looked around and found the gadget sitting at the back of a top shelf. Amusing -- rather dusty.
The schematic was still in a folder in the good ol' filing cabinet, dated 1986.
Comments
"Source code control" or "vesion management" is a procedure for keeping track of all the changes to a piece of software source code. Of course we have programs to help with this.
In the simplest case it helps you keep track of what your state your code is in. I bet you have found yourself keeping old revisions of code as you work. You know, in case your latest modification turns out to be a mistake and you want to go back to an older version. Or perhaps you want to try some experiments on your code so you copy the whole project to another directory and work on changes there. Meanwhile the original directory might still be worked on as it is the one that works. Very soon you find you have a whole hardrive full of different versions, different branches with different features and backups all over the place and before long you have no idea what is what.
A version management tool will keep a data base containing all your code. When you add changes to the code you can leave little notes attached to the change to remind you what happened. You can tag or name significant versions that work as you like. Such a tool will help you keep track of different experimental branches and help merge the experimental changes into he main branch of development when you are happy with them.
All these problems get much worse if you have a lot of code in a project and more than one person working on it. But such a version control system is briliant even when working alone.
There are many version control systems, Subversion, CVS, git, MicroSoft Visual Source Safe etc etc.
I would suggest looking at www.github.com. They use the git system as used for Linux. You keep all your code on a repository (database) on their servers, no worries there you have an exact clone of the repository on you machine as well. Git hub also keeps a wiki along with your project for all those design notes to your self and there is an issue tracking system that you can use for reporting bugs or feature requests to yourself.
You might try listing ambitions, motives, and benefits to see how a project fits in on a sustainable basis.
If you are trying to motivate others, you might trying to figure out if they are ambitious, greedy, and hungry. It really takes all three to really drive a project forward.
I realize this is a rather Machiavellian approach to the problem, but I rarely get much done as I am not ambitious, greedy, and hungry... whereas the pundits of success, Bill Gates, Steve Jobs, and that Facebook whatshisname nicely demonstrate the model.
These days a personal review of my ambitions, motives, and the benefits I seek nicely define the kind of person I want to be. I can accept that. But in earlier years, there were a lot of conflicted items and turmoil in wanting what was not to be or what was beyond my desire to reach far enough.
Sure, you can take a sterile approach and say it is all organization, administration, and time management.. but people come and go for the oddest of reasons. The ones that stay with a project are getting the most of what they want with this project regardless of what they say or how they pose themselves.
When I run into any sort of "hiccup" on a project, I jump into something else till an answer comes along. Though with so many things going on, it takes "forever" to get back to a specific task. :-|
Perhaps it would help if there were some sort of =real= deadline, but it's just me and no one cares! :-)
Amanda - The important thing to me is... it's all fun!
1) Software: I have a synchronized folder structure that is routinely backed up for all softcopy items. My folders are Books, Code, Projects, Software, and Specs. Everything I do in my hobby is in one of those folders and each has it's own set of subfolders, depending on it's complexity. In my projects folder, I currently have 73 subfolders (main projects)
2) Hardware: I keep everything organized in various sizes of "Really Useful Boxes" and nab new ones every time Staples runs them at 40% off. I try to keep larger projects in their own box of an appropriate size. I also have 6 large totes for those long term projects and 2 Grab-n-Go organizers.
3) Organization: Let me know if you find something that works. I have struggled for about 2 years trying to organize my projects. I did use a Google site to kick off my last Propeller module and it worked very well, using the project wiki template. It took a bit of playing around to learn how Google Sites worked, but I love it and use them all the time for project management at work since we use everything Google. Google Sites easily integrates Google Spreadsheets, GMail, and other features quite nicely.
I think version numbers are helpful but I don't think they are adequate for keeping track of program versions. I don't know about the rest of you but have usually end up with scores of versions of code. Keeping track of what child version goes with which parent can get a bit hairy.
Here's my method of trying to keep software versions straight. I add a date stamp to the name of the program with a version letter. I also include this name in a DAT section at the top of the program. Here's an example of the beginning of one of my programs:
DAT programName byte "DemoFourMotorsAndEncoders130215c", 0 CON {{ ******* Public Notes ******* }} { ******* Private Notes ******* 130125a Use debug statements in parent object instead of child object. DemoFourMotorsAndEncoders130125a modified from DemoFourMotors130125a. DemoFourMotorsAndEncoders130125a add encoders. 31c Comment out motor control.I often don't fill out the "Public Notes" section until I'm ready to post the code to the forum or OBEX. I usually just note the day of month and version letter when making "Private Notes". If it's been a while since I've made changes, I include the full date stamp. I also note when I change the name of the program.
The first line has the 'programName" string. I usually have this string displayed (if there is a display) when the program first starts up. This helps me know which version of the code is currently running on the Propeller.
It also helps to keep track of which child object was being used at the time. Here's the OBJ section of this example.
By having the version information in the program name, it's much easier to keep track of which parent object used which child object.
This may seem pedantic but I have found it to be very useful.
For those how may not think this is pedantic, just wait, it gets worse better.
I often want to have the names of the child objects displayed so I include methods like these in the child objects.
I have a feeling I'm going about this the hard way. I bet the version control software others have mentioned would keep track of this stuff for me if I were inclined to learn to use it. I don't know enough about version control to know what I'd have to gain by taking the time to learn to use it.
I'd be interested to know if one of the version control services is a better fit for Propeller programs than another. If I'm going to learn to use version control, I'd rather just learn one version of it.
Someone here on the forum (I think it was Roy Eltham) suggested using DropBox to make sharing files between computers easier. I liked DropBox so much, I moved all my Spin code into the DropBox. Now I can access the latest version of my Propeller programs from any of the computers I use.
If any of you haven't tried DropBox, use this link so we can both get an extra 500MB of free storage.
Now I just need to finish the robot to put away my stuff (and retrieve a cold beverage from the frig).
Jeff
DEVELOPMENT VERSIONING 000 - Started with Google Earth KML Logger. Modified pin assignments for my demo board setup (currently no switch, assigned to unused pin) 001 - Added LED2 for "is Longitude > 99" status check 002 - changed atoi string from 3 to 4 003 - Added multiple longitude routines for debugging 004 - Modified longitude routines for debugging 005 - Removed extra longitude routines, kept working one 006 - Resequenced longitude and latitude routines 007 - Resequenced longitude and latitude routines, updated header and footer in fake dat section, added switch at P0 P08 - Moved to PPDB, added uOLED, stripped down code P09 - Modified display features P10 - Added Servo functions P11 - Added Matching routine to Longitude (green value means match) and SW01 unlock bypass routine P12 - Added Matching routine to Latitude, minor housekeeping, set lat/lon to Parallax, LED2 commented out U14 - Moved to USB Protoboard, changed pinouts U15 - This was the "5:15am on birthday morning but it works!" version. (12/21/09) U16 - Final clean up/commenting for posting on completed projects forum. (1/1/10)Keep a TODO list - this helps tremendously.
Set goals and rewards to help stay on track.
Use a source control system even if you're the only developer.
Don't read the forums until you've achieved something useful.
I find version numbers to be more trouble than they are worth for software.
Interesting observation about version numbers. Some people seem to never get the software to 1.0 even though it is quite stable and useful, others dramatically jump up in numbers and confound the users with hyperbole of the newest is the best.
Linux recently went from 2.6 to 3.0 for the sake of promoting a new era of stability, but I doubt many really understood. Meanwhile the boot loader for Linux, called Grub hung on to 0.99 forever and suddenly created Grub2, and then renamed Grub2 to be Grub 1.99.
The real key here is a real revision control system that allows you to progress AND to have forks if you choose to wander. An online archive is likely more useful for this that a complete DIY set up. You have the opportunity to share and collaborate if you desire.
As you run around the edit, compile, test loop you can have a dozen variations of code per day, or hour depending on your style.
Then what you are hacking today may be an experimental new feature in a branch of the code, so it's versions are totally unconnected with that of the main branch.
You may have many branches at once as you tackle different features or bug fixes.
Then on bigger projects there may be multiple developers all with their own branches and "micro versions".
Enter something like git which does not care about versions so much, It cares about content and changes. You may not commit every little edit you make in a day but you may find you make a commit every time you are satisfied with some feature. That can still be multilple times per day. Same for your collaborators. Every one of those commits is tracked by git not as a vesion number but as an SHA1 hash of the differences that you have made between the last commit and the one before it.
So in git the developers need not think about version numbers, git effectively does that for you.
No, version numbers are for the users of your code. At some point you release something to the world and people use it. As you progress you release new and hopefully better versions. But it can happen that your new version introduces a bug or is some how incompatible with the older versions. Say you have changed a config file format or names of commands etc. Well then the users cannot take that new version into use until they have tweaked their system to accomodate it. They will still want the older version for a while at least.
Users need version numbers so that they can be sure to get hold a version of the code that works for them.
To satisfy that user problem developers should put version tags on their released code:
$ git tag -a v1.2 -m "Version 1.2 release"
I said "something like git". I'm beginning to think there is nothing else like git. It's the best version control system I have ever used. Even if it does take a bit of getting used to.
Git is a bit tough to get started with if you have been using other version control systems for a long while. "What two people can be changing the same file at the same time! How can that work out?"
You don't have to be online all the time to use it because basically you have a clone of the repository on your local machine. Just make your edits, commit the changes to your local repo and then push them to github when you want. That also means that if github disappears one day you still have the exact same source and change history locally and can migrate elsewhere if need be.
Downside with github is that if you use their free repository service then it is open for the world to read and download. If you want private repositories it costs a few dollars a month.
In my current idealization of "organized" my hard drive would have nothing on it except when I want to work on it or use it. Like having a cleared desktop. All my little projects would be neatly filed away in github and backed up elsewhere in the cloud just in case.
Thanks for taking time to explain a bit how github works.
In your opinion, would the effort needed to learn to use Github be worth the benefits for a single developer of Propeller (Spin/PASM) only software?
A what????? You mean there's a flat surface under there?
Yes, yes and yes. Many lone developers even on small projects have expressed the opinion that using version control has helped them. It gives you great piece of mind that everything is in order and you entire projects history is recorded so that you can always recover any damage you do. No faffing about with billions of different versions of the same files and not remembering which one went with which.
Git can be daunting but the normal work flow is very simple. There are now some nice GUI tools to help if you need and there are lots of tutorials around. Github itself as some good stuff.
You can look at it like this: There is no such thing as a single developer of a project that takes more than five minutes to complete. If you leave your project for a day, a week or a month when you get back to it you may not remember where you were or why. In a way you are not the same developer that left it last.
Have you ever found your self thinking "What idiot wrote this code?" whilst reading some code you wrote yourself!:)
If so you need version control and change history.
Well, I was just guessing...
the latter is One I have dealt with ..... but the former is not as easy ........Esp considering many of my projrcts are not one size ........
Peter..
I took this thread to be more psychological than practical. As in the phrase "back in the groove". Staying in the "groove" is a lot psychological but making the practical stuff, both software and hardware organization, easier can help a lot.
I was mostly referring to the IP aspect, things that can be handled with notes, drawings, etc., either on paper or electronic.
The physical aspect is important as well, so both are on topic as far as I'm concerned.
C.W.
Published program version numbers are useful for keeping track of features, bug fixes, and other what-nots.
Having source control allows tracibility on all commited changes between published program versions.
Posting code on the forums is one way to make snapshots of projects, but finding it years later can be almost impossible.
BTW, any PCB and docs should get version numbers whether they are released or not - they cost money and should have easy references.
That way you now know that your code and schematics work together when you check out the last know good tested version.
The other thing is asking "is this important to my main goal" and put stuff away if its not the critical path. Actually, I have a big shop and don't have to put stuff away for a long time, and stuff tends to get buried and lost, but you get the idea.
The last thing is notes, as other folks have said. I know when I read my notes I will have forgotten everything about the project, so I put enough detail so a n00b can produce the correct result.
Each project gets its own folder including any modified library objects, and each deployed release gets zipped into a dated file. Always keep a working prototype of any device developed or sold to anyone else. Has to be included in the cost of business.
When Gareth was asking about the line algorithm, I recalled a piece of hardware I made to draw cycloids on an X-Y display of an oscilloscope for a science exhibit. I looked around and found the gadget sitting at the back of a top shelf. Amusing -- rather dusty.
The schematic was still in a folder in the good ol' filing cabinet, dated 1986.