On Mar 11, 2014, at 5:38 PM, Evan Huus <eapa...@gmail.com> wrote: > On Tue, Mar 11, 2014 at 5:34 PM, Hadriel Kaplan > <hadriel.kap...@oracle.com> 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? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
