Daniele Segato <daniele.bilug@xxxxxxxxx> writes:
> I only can think of doing a backup of my build.properties, delete it
> and check out the tag or I just delete it and rebuild
> it from the template later.
That is the right approach, but you could automate it further.
The project I help at work has a similar set-up. The Makefile defines a
plain vanilla set of configuration via the Make variables, and they can be
overriden by including ./config.mk. The master branch does not have the
file tracked, but ./config.mk-sample file is tracked and the developers
can use it as a template.
The developers can have an untracked (from the project's point of view)
subdirectory, local/. with local/myconfig.mk file. "local" is in fact a
full fledged git repository with local/.git and changes to myconfig.mk can
be tracked there. It is not (and should not be) a subproject.
Because what appear in the sample config.mk-sample are a bunch of Make
variable definitions, and in Make, later definition trumps the earlier
ones, So the developers can do:
$ cat config.mk-sample local/myconfig.mk >config.mk
$ make
The first step can be in the Makefile; the above command line is for
illustration.
For branches that are used for specific customer release, we track their
config.mk file. That means the developer would lose config.mk file if he
does this:
$ git checkout master
$ cat config.mk-sample local/myconfig.mk >config.mk
$ make
... do the usual work of developing and testing ...
$ git checkout customer ;# may fail due to config.mk
$ rm -f config.mk ;# so get rid of it
$ git checkout customer ;# now it is ok
$ make ;# for real release
... or perhaps to diagnose the issue at customer site ...
$ edit config.mk ;# minimally adjust for testing
$ make
$ test
... done, and go back to the regular programming ...
$ git checkout config.mk ;# get rid of local changes
$ git checkout master
But because the real configuration is tracked in local/.git, there is no
information lossage.
The generic config.mk _could_ be written to include local/myconfig.mk if
exists, in order to help debugging or testing the customer branch (then
there is no need for "edit config.mk for testing and then revert" steps),
but we chose not to do so, as it risks the release/build engineer to
forget that he has funny customization in his local/myconfig.mk file and
screwing up the release by inadvertently including the customization.
HTH ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html