Re: [git-users] Git / vcs newbie question: Sharing changes between branches
Hi Konstantin & Gergely,
in principle I understand the concept of modularization.
My problem is that the differences in the code are on multiple
layers that make it very hard to modularize. I'll give some real
examples (bootloader for an embedded device) and detail:
a) Basic Setup: Device should accept firmware updates on pushing a
certain button-combination. Then it should do a memory test. If
there's no firmware update, it should boot the installed firmware.
If the buttons are pressed, it should receive a firmware update
over a usb connection an install it into flash.
b) Customer wants a device without buttons, so it should wait for a
firmware update for 15 seconds and then boot the installed firmware
if no update is received
Currently, most of this is implemented in the main() function. As
far as I know, one concept of C is that some crt0()-function
sets up the environt. When using a "clean" approach, as soon
as main() is called, everything should be set up correctly: Stack
pointer, ram modules, etc.
The ram test routine however destroys the contents of the memory, so
it should happen before calling main(). Currently checking the
button status happens IN main(), but the ram test should happen
afterwards ...
Looks like the code needs some refactoring ;-)
Yeah, I see this is getting off topic, so I'll stop here. Just
wanted to let you know what I'm actually talking about.
Thanks for pointing to StackOverflow and the comp.lang.c newsgroup,
might be helpful soon ...
Cheers
Michael
On Wed, 25 Sep 2013 18:07:11 +0400
Konstantin Khomoutov wrote:
> On Wed, 25 Sep 2013 02:36:39 -0700 (PDT)
> Michael Weise wrote:
>
> [...]
> > One problem I'm facing is that we have different customers who get
> > different versions of our program (programming language is C).
> > Currently these versions are implemented with lots of #ifdefs that
> > make the code hard to read.
>
> Not sure if this applicable to your particular situation but one way to
> go about solving this is modularising: you extract all the common code
> to a library (static or dynamic -- depends on the exact requirements)
> and then write a *separate* program for each customer, and each would
> use the library by linking with it. Yes, this *is* code duplication
> as these separate programs will have much in common and possibly even
> some exact parts but it's quite possibly this won't be code you change
> much.
>
> A refinement to this approach is to turn functions which have #ifdef-ed
> code into several (similar) functions each, or may be a single
> -- "framework" -- function which, when called, receives one of more
> pointers to other functions which provide bits currently coded inside
> #ifdefs, like this:
>
> int foo()
> {
> int x;
> x = quux();
> #ifdef SOME
> blurb(&x);
> #else
> mumble(&x);
> #endif /* SOME */
> return x;
> }
>
> turns into
>
> typedef void (* handle_x_fn) (int *); // see [1], for instance
>
> int foo(handle_x_fn fn)
> {
> int x;
> x = quux();
> fn(&x);
> return x;
> }
>
> which is then called
>
> y = foo(&blurb);
> or
> y = foo(&mumble);
>
> depending on which customer's program this is, with foo() being located
> in the library both programs share.
>
> This is called modularisation.
> I've consciously diverged from the topic in the hope this would be of
> some help, but if it is, you're better off asking about the exact
> techniques for modularisation in C using other venues such as Stack
> Overflow and comp.lang.c newsgroup available here on Google Groups.
>
> Hope this helps.
>
> 1. http://stackoverflow.com/a/1591492/720999
>
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Git / vcs newbie question: Sharing changes between branches
Although totally independent from Git itself, I think this is the point where shared libraries come in to the picture. For example, you may want to "outsource" the common work to a shared library, and maybe add this library either as a compile time dependency, or as a git-subtree; both would mean that you have to manage N+1 repository, where N is the number of customers and +1 is your library. Cheers, Gergely On 25 Sep 2013 11:36, "Michael Weise" wrote: > Hello folks, > > I've just started to work on a software project with lots of "dirty" code > with very little to no management, no bug tracking, no documenatition at > all. As one of many actions, I decided it would be a good idea to use a > version control system and git looks like a suitable choice. > > Some background info about myself: I'm an electrical engineer, have done > some programming here and there, but this is my first big "real" software > project. I do know stuff about hardware, have compiled plenty of programs > from source, BUT I'm not familiar with concepts that "real programmers" ;-) > know about, so I'll be thankful for some hints. I've never used a version > control system before (except for downloading, e.g. "git clone ..."). > > > One problem I'm facing is that we have different customers who get > different versions of our program (programming language is C). Currently > these versions are implemented with lots of #ifdefs that make the code hard > to read. > > I wonder if I can solve part of the problem with version control: > > Let's say I have source code for customer A that works fine. Now customer > B wants the same program, but with subtle changes in different places of > the code. > > How would I handle that? > > a) One approach is to create a second branch for customer B and apply the > changes. But when I have to make changes that apply to both (or lets say > n=12) branches, how would I do that? > This would lead to a situation, where I have (at least) 12 branches for 12 > customers, which might diverge more and more over time (not generally a > problem, but maybe incompatible to the idea behind version control?). > > b) Another approach is to keep one codebase with all the #ifdefs and use > version control "in the classical way". > > What do you recommend? Is there another approach worth considering? > > Regards > Michael > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Git / vcs newbie question: Sharing changes between branches
On Wed, 25 Sep 2013 02:36:39 -0700 (PDT)
Michael Weise wrote:
[...]
> One problem I'm facing is that we have different customers who get
> different versions of our program (programming language is C).
> Currently these versions are implemented with lots of #ifdefs that
> make the code hard to read.
Not sure if this applicable to your particular situation but one way to
go about solving this is modularising: you extract all the common code
to a library (static or dynamic -- depends on the exact requirements)
and then write a *separate* program for each customer, and each would
use the library by linking with it. Yes, this *is* code duplication
as these separate programs will have much in common and possibly even
some exact parts but it's quite possibly this won't be code you change
much.
A refinement to this approach is to turn functions which have #ifdef-ed
code into several (similar) functions each, or may be a single
-- "framework" -- function which, when called, receives one of more
pointers to other functions which provide bits currently coded inside
#ifdefs, like this:
int foo()
{
int x;
x = quux();
#ifdef SOME
blurb(&x);
#else
mumble(&x);
#endif /* SOME */
return x;
}
turns into
typedef void (* handle_x_fn) (int *); // see [1], for instance
int foo(handle_x_fn fn)
{
int x;
x = quux();
fn(&x);
return x;
}
which is then called
y = foo(&blurb);
or
y = foo(&mumble);
depending on which customer's program this is, with foo() being located
in the library both programs share.
This is called modularisation.
I've consciously diverged from the topic in the hope this would be of
some help, but if it is, you're better off asking about the exact
techniques for modularisation in C using other venues such as Stack
Overflow and comp.lang.c newsgroup available here on Google Groups.
Hope this helps.
1. http://stackoverflow.com/a/1591492/720999
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Git / vcs newbie question: Sharing changes between branches
On 25 September 2013 19:36, Michael Weise wrote: > I decided it would be a good idea to use a > version control system and git looks like a suitable choice. Yes and yes! I am an EE and write some C. I agree with Alex's comments. It might be much cleaner to handle some of the customer difference logic in the executable C, rather than conditional compiles. You could implement a set of meaningful flags, and use combinations of those flags to describe the requirements for each customer. The rest of my message ignores this issue; it is intended to encourage you that git is a useful tool to help you try all solution approaches, including this one. > One problem I'm facing is that we have different customers who get different > versions of our program (programming language is C). Currently these > versions are implemented with lots of #ifdefs that make the code hard to > read. > > I wonder if I can solve part of the problem with version control: Yes, git is suitable for this. > Let's say I have source code for customer A that works fine. Now customer B > wants the same program, but with subtle changes in different places of the > code. > > How would I handle that? > > a) One approach is to create a second branch for customer B and apply the > changes. But when I have to make changes that apply to both (or lets say > n=12) branches, how would I do that? > This would lead to a situation, where I have (at least) 12 branches for 12 > customers, which might diverge more and more over time (not generally a > problem, but maybe incompatible to the idea behind version control?). > > b) Another approach is to keep one codebase with all the #ifdefs and use > version control "in the classical way". Your options a) and b) are not mutually exclusive, I'd encourage doing both, in one git repository. git is a good tool for managing both alongside one another. I would start by putting the existing code into git [your option b) ] and then use git to manage your experiments with moving towards a) at your own pace. Assuming that most of the code is used for all customers, my approach would be first from the existing code to create a 'clean' branch with no customer #ifdefs. Then create another code corresponding to the effect of the #ifdefs only for customer B. The diff between that code and the 'clean' branch would then become branch 'B' off the tip of 'clean'. Later changes just for customer B will be stored in branch 'B'. When necessary you can make improvements on the 'clean' branch, and then "rebase" any customer branches to branch off whatever point in 'clean' that is necessary to pick up those changes. git can diff between branches, and between commits, so you can always see the diffs, and cherry pick those diffs to other branches (customer or 'clean') wherever they might be needed. My favorite git tip, because it took me far too long to understand this: branches are not code, just pointers to code. Whenever you want to do anything you are not sure of to a branch, don't stress, simply duplicate the branch (not the code, you just create another pointer to the same code) and manipulate that one. If something unexpected happens, the original is unchanged as a fallback. When you get the desired result, just delete the fallback. It took me some time to get comfortable with git. Now that I am, I find it indispensable. I recommend the graphical tools, and doing lots of non-critical experiments after making a safety copy of the .git directory somewhere. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Git / vcs newbie question: Sharing changes between branches
Hello folks, I've just started to work on a software project with lots of "dirty" code with very little to no management, no bug tracking, no documenatition at all. As one of many actions, I decided it would be a good idea to use a version control system and git looks like a suitable choice. Some background info about myself: I'm an electrical engineer, have done some programming here and there, but this is my first big "real" software project. I do know stuff about hardware, have compiled plenty of programs from source, BUT I'm not familiar with concepts that "real programmers" ;-) know about, so I'll be thankful for some hints. I've never used a version control system before (except for downloading, e.g. "git clone ..."). One problem I'm facing is that we have different customers who get different versions of our program (programming language is C). Currently these versions are implemented with lots of #ifdefs that make the code hard to read. I wonder if I can solve part of the problem with version control: Let's say I have source code for customer A that works fine. Now customer B wants the same program, but with subtle changes in different places of the code. How would I handle that? a) One approach is to create a second branch for customer B and apply the changes. But when I have to make changes that apply to both (or lets say n=12) branches, how would I do that? This would lead to a situation, where I have (at least) 12 branches for 12 customers, which might diverge more and more over time (not generally a problem, but maybe incompatible to the idea behind version control?). b) Another approach is to keep one codebase with all the #ifdefs and use version control "in the classical way". What do you recommend? Is there another approach worth considering? Regards Michael -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
