Source Control

[Jay Lash]

This is my first participation in an open source project, and my first
participation in a project in a very long time where there are
different people making modifications to serve different needs and any
particular user can pick and choose what he wants to apply.

Ive started the discussion about a config.h for enabling/disabling
different mods. But Im looking for some discussion on how we actually
make the mods available.

* It doesnt seem like it will work for everyone to simply add mods to
the main branch of code. Even if they are #ifdef protected there will
surely be conflicts.

* It doesnt seem like it will work to use diff/merge because the code
base you want to merge into is very likely not the same as the code
base I generated the diff from.

Way back in the day (before Al Gore invented the internet ;-) I used
the WWIV bulletin board system. Mods to that were distributed as a
set of instructions: "find this chunk of code in X source file and
change it to look like this". This still has potential for issues
when "this chunk of code" can not be located because some other mod
already replaced it.

And some related discussion - when is it appropriate to check in
changes to the main code base?

Thanks

[Keenan Tims]

> * It doesnt seem like it will work for everyone to simply add mods to
> the main branch of code. Even if they are #ifdef protected there will
> surely be conflicts.

This is basically something that Steve, or whoever is going to be
responsible for the project, just needs to decide on. Embedded
development tends to be pretty inflexible in this regard (though with
sufficient foresight and lots of preprocessor magic you can make
almost anything configurable), so he's just going to have to decide
which mods make it into the main project. Anything that goes outside
the scope of the project probably needs to be maintained in a complete
fork, with patches from Steve's project backported manually (or
semi-automatically with Git or such).

If lots of independent forks is where this project is heading it
probably makes sense to move the main development off of Subversion
onto a distributed RCS.

> * It doesnt seem like it will work to use diff/merge because the code
> base you want to merge into is very likely not the same as the code
> base I generated the diff from.

The usual approach with traditional revision control is to check out a
specific revision and then diff against that. The project maintainer
can then branch against that revision and merge back to trunk.
Distributed revision control should handle this automagically as long
as there aren't conflicts.

> Way back in the day (before Al Gore invented the internet ;-) I used
> the WWIV bulletin board system. Mods to that were distributed as a
> set of instructions: "find this chunk of code in X source file and
> change it to look like this". This still has potential for issues
> when "this chunk of code" can not be located because some other mod
> already replaced it.

Personally I don't think there's much sense in worrying about easy
application of patches for an embedded project. Only developers are
ever going to be capable of utilizing them effectively, beyond
applying a single patch (which that patch's developer can just
distribute in binary form or via a fork). A patch against a particular
release version is fine; if developers then want to integrate a few
patches from different people, 'patch' should be just as good as the
sort of instructions you mention, and manual intervention is still a
strong possibility. Patches are fairly human readable too, for the
sort of humans that are going to be using them.

Cheers, and if your config.h indicates the mods you've made already, I
for one will be happy to use them on my own device!

Keenan

[EBo]

I'm not sure if you all would be interested, but a few years ago I
tweaked some of automated regression testing tools to run on embedded
systems via JTAG. It was great for testing little modules. If setting
this up is of general interest we can look into it.

Also, have people settled on a specific revision control system
(git/mercurial/subversion/...)?

EBo --

[Steve Chamberlin]

The code is in a Subversion repository hosted by Google Code: http://code.google.com/p/backwoods-logger/source/browse/#svn%2Ftrunk

Steve

[Jay Lash]

That makes sense Keenan, thanks for the descriptions.

If Im thinking about it correctly there seem to be three types of
modifications to consider:

1) general improvements that get rolled directly into the code base
(the altitude range/resolution stuff)
This implies a person or people to approve incorporating the changes
into the main code base. Which is what Steve said in the other thread
when he asked that I send him a diff to review before he added me to
SVN as a submitter.

2) customizations of general interest that are added to the code base
and must be enabled via config.h (the daily high/low stuff)
Same as above but maybe less restrictive in what is approved for
inclusion?

3) things that are not so general or are more involved and are made
available via diff (i.e. things that conflict with other mods or that
have more significant size/performance implications)
This implies that mods will need to be reapplied and new diffs
generated for each new release of the code.

[Steve Chamberlin]

Sure, that sounds about right to me too.

I'm hopeful that nothing will fall into category 3-- is there something in particular you're thinking of? If two mods conflict, like two different lock screen mods, they can still be handled using the config.h method as long as they're not both enabled at the same time. I'm thinking that anything falling into category 3 is hopefully rare, and can be dealt with on a case-by-case basis, to decide if it's more appropriate as a patch, a fork, a reorganization of the code, or something else.

Steve