Hi David,

haha, looks like our minds work in a similar way. I also started
disliking the "one branch per customer" approach.

I was planning some kind of refactoring anyway, so using git as a
VCS will be part of it.

Cheers
Christoph


On Thu, 26 Sep 2013 16:25:04 +1000
David <bouncingc...@gmail.com> wrote:

> On 25 September 2013 22:23, Michael Weise <michael.we...@ek-team.de> wrote:
> >
> > Thanks a lot guys, this was exactly the kind of information I was looking 
> > for!
> 
> Hi again Michael
> 
> I just came across this today, I recommend it:
> https://github.com/pluralsight/git-internals-pdf/releases
> (click on the pdf download button)
> 
> Also, I'm writing again because I'm feeling its necessary to clarify my 
> previous
> message ... its aim was to convey my view that git would assist your project,
> and that point stands.
> 
> However, as part of illustrating that for you in terms that you would relate 
> to
> your project, I gave an example of how you might use git to create separate
> branches for each customer. But ... the more I think about this as a proposed
> architecture, the more I dislike it. It is not zero work to manage all those
> branches, and I feel sure there must be simpler ways to solve the problem.
> 
> So I still encourage you to use git, but I suggest you could use it to plan
> and implement a transition towards a better code structure than the one
> I used in that example.
> 
> Restating what I wrote before:
> > 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.
> 
> That way, the codebase could be the same for every customer. There could
> be one file that defines what feature flags are enabled for each customer.
> 
> You could do that with #ifdefs, or preferably in other nicer ways. #ifdefs are
> ugly. They are good for keeping code out of the build, to keep it small or
> ensure that customers can't reverse engineer access to features they haven't
> paid for. If those issues are not important, then in your situation I would 
> work
> towards refactoring out the #ifdefs in favour of some other method that is
> clearer and easier to maintain.
> 
> -- 
> 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.


-- 
Michael Weise <michael.we...@ek-team.de>

-- 
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.

Reply via email to