Vitaliy wrote:
> Brilliant. Your solution works as advertized and does exactly what I asked 
> for.

Hey, great!

> One question though -- how do you do an SVN Copy from TortoiseSVN?

First, create the new project folder and Import it as usual - just to 
give you an SVN-enabled target.

Then, select the files you want to copy from the old project and 
right-drag them to the new folder.  The popup menu has an option for 
"SVN Copy and add files to this WC".

Not very discoverable, but simple once you know!

> A somewhat unrelated question: suppose instead of "reuse" you have a bunch 
> of custom libs (uart, i2c, pwm, eeprom, etc). Would you keep them all in one 
> repository (in their own subfolders), or would you put each one in its 
> individual repository?

The same repository is fine.  And there's a similar question about the 
'trunk' convention; I prefer it like this:

https://path/to/my.repository.com
   branches/
     MyDumbProject/
       attempt to use trinary integers/
       starting port to FORTRAN/
     Whizzy experiment/
   tags/
     MyDumbProject v2.0 RC1/
     MyWhizzyProject v1.0 GM/
   trunk/
     reuse/
       uart/
       i2c/
       ...
     MyDumbProject/
     MyWhizzyProject/
     ...

I don't use branches and tags often enough to need to keep a separate 
set of (branches, tags, trunk) for each project.  So they're all mixed 
together in tags/, which seems fine - I just put project names into the 
tag names as shown.  Sometimes branches/ has subfolders and sometimes 
not, as shown.

I do have separate top-level folders for stuff that's accessed by a 
different set of people.  E.g., I have an apprentice who's working on 
his own projects and doesn't need (and shouldn't have) access to my main 
work files.  So the actual repo looks something like this:

https://path/to/my.repository.com
   mycompany/
     branches/
     tags/
     trunk/
   apprentice/
     branches/
     tags/
     trunk/

I also have a completely separate repository for one client who needs 
regular access to source, and for whom it's reasonably possible that I'd 
want to move the whole repo to another server at some point, or to 
another domain.

> On the subject of regression testing, do you practice test driven design 
> (write the tests first, then the actual code)? It sounds like a great idea, 
> but I haven't been able to consistently/effectively apply it in the embedded 
> world.

Me neither.  I'm more likely to do it in desktop apps where I already 
have an automated testing framework with a rich UI - or at least where 
it's easier to write a unit test that spits out a readable log.  Most of 
my embedded designs don't even have an LCD.

I feel like it's worth exploring, though.  I "invented" it years ago 
when writing utility classes in C++, and I've found it very helpful when 
I've used it.

In some sense, writing a detailed UI spec or even a clear state diagram 
is fairly similar to writing a test case first - or it's useful for the 
same reasons.

> It would be nice if there was function overloading in C...

BoostC has that too.  Of course it's non-portable though.

> I think something else that is helpful, is keeping the number of 
> "public" functions to a minimum.

Yes - I only make something public at the moment I need to use it elsewhere.

>> Beyond that, perfect design, clairvoyance, and general brilliance are
>> necessary.  :)  (Or instead, grumbling and swearing.)
> 
> I can't pass the first set of requirements, so I guess -- grumbling and 
> swearing it is. :o)

They are more readily available, and on more days.  :)
-- 
Timothy J. Weber
http://timothyweber.org
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist