On Mar 11, 2014, at 5:38 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
> On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan
> <hadriel.kaplan@xxxxxxxxxx> wrote:
>>
>> Googling around a bit for this issue - because other apps must have this same problem and their users - shows people either creating a ton of tags, or scripting with the rev-list count to generate sequential numbers in their commits to master.
>>
>> How did SVN deal with a rev number in older branches, when you either backported a change from a newer release or committed a change only to the older release? Did it use the same rev number, or give it a new one? (ie, was it the same/shared numberspace?)
>
> It gave it a new one (just like backported git revs get new SHAs) but
> that's not really the problem. The problem is that the user only knows
> their build was at some particular SHA; they don't know whether the
> SHA they're interested in came before or after it.
No, but I was already jumping ahead to a possible (crazy) solution. :)
Since SVN used a single number space but gave each branch's commits new numbers, you can create a new "revision" string that looks like "<tag>:<number>", where <tag> is the branch tag and <number> is the rev-list count of origin HEAD for each branch. The <tag> keeps them unique per branch, and also quickly tells the user which release branch that change is in.
Is there a way to have a hook script that only takes effect when committing into the master branches? (ie, only when you guys cherry-pick and commit a change to the real master/master-x.x repositories?) If so, you could create a script which gets invoked during the cherry-pick commit into master/master-x.x, which inserts this "<tag>:<number>" string into the commit message.[1] For example adds a "Revision: 1.11:12345" to the end of the commit message, similar to the commit-msg Change-ID line.
That way backporting also appends additional revision info lines to the commit message, and each one is unique/identifiable by the <tag> portion.
Copy that "<tag>:<number>" into the cherry-pick message you guys post on gerrit reviews (or is that scripted too?). And lastly, when the buildbots build a new nightly or tagged release, have them use the rev-list count for the given branch being built, for the binary file name and about-page info in the build.
-hadriel
[1] making it an atomic operation might be tricky though - dunno anything about how git does that. Might want to have the <number> be stored in a git-controlled file, in each repository?