On Tue, 28 Oct 2014 17:49:55 -0700 (PDT)
guru prasad <gupr1...@gmail.com> wrote:

> Now my question is if the project version is
> then I can put this in the archive version so I can see it on
> the runtime but I also want to be able to correlate the version of
> the config file. The config file has Dev, QA, QA perf, PRD
> Now when I deploy I want to be able to deploy with (1.2
> being the version of Dev config file) something like this.
> Am I completely off track? Not sure how to individual keep track of
> the 4 config files in the config project folder so that I can deploy
> dev changes separately with dev version number, QA with QA number
> etc.,

It's not really clear what exactly do you want to achieve.

You can't have Git somehow automatically use/track/modify/apply those
version numbers because Git does not know anything about them.
But I suppose you can leverage Git in one way or another to help you
maintaining these version numbers.

What comes to my mind is:

1) Have two special files in your repository: one containing the
   project version and another containing the config version.
   Make the archive generation tool read them but not include them
   into the archive it generates.

   Normally, these files should be empty or contain some template
   values, like "A.B.C.D" and "X.Y" respectively, then, during the
   release cycle of a particular S/W revision, the branch tracking this
   would receive two technical commits: one populating the app version
   file and another one populating the file with configuration version.

2) Use tags of special format understood by the archive generation tool.
   Again, during the release cycle of your software product, once the
   devs release their code, tag it using something like "app-v1.2.3.4".
   Then, when another set of changes is done to prepare a particular
   configuration tag the resulting commit with something like

   When generating the archive, use

     git describe --tags --match 'app-v*' <commit>

   to obtain the nearest "application version" tag, then

     git describe --tags --match 'conf-v*' <commit>

   to obtain the nearest "config version" tag, parse out version numbers
   from then and construct the resulting version.

   You can then tag <commit> with a combined tag, say, simply
   "v1.2.3.4:1.2" to be able to easily locate this version afterwards
   when a support request comes in.

3) Just use branches named after version numbers.
   Say, when you're about to start a release cycle of a particular
   version of your software, fork a branch named "v1.2.3.4" off the
   point the dev team blessed as ready for release.
   When you need to apply certain configuration to it, fork another
   branch off "v1.2.3.4" and name it "v1.2.3.4:1.2".

I'm not sure I fully understood your requirements but at least all
that might fuel your imagination.

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/d/optout.

Reply via email to