What are the best means of keeping track of the development stages of your project that have been proved by yourself to be effective so you don't forget what you did some time ago and being able to start with your development time?
Do you use heavy documentation? A very distributed source tree? Just a definition of source/object modules? Or do you use a combination of those and/or something else?
How Do You Track Your Project?
-
Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Have you heard of Version Control software? lmao..
Using something like SVN or CVS will allow you to keep track of things..
If you want to see when you added support for something you can browse log messages..
Version control is very handy.. You can compare between revisions, With SVN there is a handy feature called blame which is very nice if you're working with many people.
Using something like SVN or CVS will allow you to keep track of things..
If you want to see when you added support for something you can browse log messages..
Version control is very handy.. You can compare between revisions, With SVN there is a handy feature called blame which is very nice if you're working with many people.
Last edited by Brynet-Inc on Tue Apr 10, 2007 11:10 am, edited 1 time in total.
Re: How Do You Track Your Project?
Hi,
In theory I write the documentation for a module (describing what it's meant to do and the interfaces it's meant to provide) before I begin writing the code. In practice I'm sloppy (the general design has become entrenched into my mind, and minor details can change during implementation) so I typically end up doing a rough draft then improve on it while I'm implementing the code and end up with about half the documentation I should have had.
To avoid forgetting what I did a long time ago I try to implement each module entirely before starting the next module. At the moment this means I'm working on boot code that parses ACPI SLIT tables and sorts out locality information for NUMA machines, even though I still haven't started any part of the kernel.
It seems slow and sometimes it's not possible to only work on one module, but there's very little back-tracking and (hopefully) very little rewriting.
As a comparison, it would be possible for me to skip a lot of things (SMP, NUMA, page colouring, full CPU detection, long mode, etc) and get a basic kernel running, but then I'd need to revisit everything I'd done and try to add support for new features that weren't originally considered. I've tried this method before and found that (for me) it causes large amounts of broken code (often followed by starting again from scratch).
Of course what works for me may not work for other people. For example, using version control software works for most people (but I hate it and prefer copying the project's directory every now and then).
Cheers,
Brendan
My project is a little different than most in that it's very modular and there's distinct boundaries between the modules (i.e. they're seperate binaries).~ wrote:What are the best means of keeping track of the development stages of your project that have been proved by yourself to be effective so you don't forget what you did some time ago and being able to start with your development time?
In theory I write the documentation for a module (describing what it's meant to do and the interfaces it's meant to provide) before I begin writing the code. In practice I'm sloppy (the general design has become entrenched into my mind, and minor details can change during implementation) so I typically end up doing a rough draft then improve on it while I'm implementing the code and end up with about half the documentation I should have had.
All modules are organised into a hierarchical tree of HTML pages, beginning with a brief overview of the project at the top of the tree and getting more and more detailed as you go down, until you reach source code at the ends. Because my source code is auto-converted into HTML the entire tree (all documentation and source) becomes my OS's web page.~ wrote:Do you use heavy documentation? A very distributed source tree? Just a definition of source/object modules? Or do you use a combination of those and/or something else?
To avoid forgetting what I did a long time ago I try to implement each module entirely before starting the next module. At the moment this means I'm working on boot code that parses ACPI SLIT tables and sorts out locality information for NUMA machines, even though I still haven't started any part of the kernel.
It seems slow and sometimes it's not possible to only work on one module, but there's very little back-tracking and (hopefully) very little rewriting.
As a comparison, it would be possible for me to skip a lot of things (SMP, NUMA, page colouring, full CPU detection, long mode, etc) and get a basic kernel running, but then I'd need to revisit everything I'd done and try to add support for new features that weren't originally considered. I've tried this method before and found that (for me) it causes large amounts of broken code (often followed by starting again from scratch).
Of course what works for me may not work for other people. For example, using version control software works for most people (but I hate it and prefer copying the project's directory every now and then).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.