[lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Chris Matthews via lldb-dev]

With svn the the IDs are unique in, so r123 implies a branch.  svn log —revision=123:234 give the right change list when svn is directed at that branch. So right now, I can get the change list in one command easily without a script.

llvmlab bisect already encodes branch information in the build name.

If LNT is the only holdout I suggest we update the LNT model to natively handle git.  The order model has other problems besides this, and I think it would make LNT more useful to capture changes in a richer way. Something along the lines of registering repos with LNT, and having orders generated based on unique combinations of hashes. That would also allow us to track changes in the CI drivers, LNT and the test-suite as first class entities in the change list. That would also allow us to show change messages in the LNT interface. Basically internalizing the sequential ID as an order ID, but then usefully representing that in the interface. This sort of change to the guts of how LNT works is weeks of work, but I think it matches LNT’s goal of tracking performance changes as software evolves.


On July 8, 2016 at 9:45:07 AM, Mehdi Amini (mehdi.amini at apple.com) wrote:



Sent from my iPhone  

> On Jul 8, 2016, at 9:18 AM, Renato Golin <renato.golin at linaro.org> wrote:  
>  
>> On 8 July 2016 at 03:14, Robinson, Paul <paul.robinson at sony.com> wrote:  
>> I could see wanting to compare data from master and a release branch. If  
>> that means sequential IDs need to work across branches, then we're back to  
>> needing a fancier solution than 'rev-list –count'.  
>  
> How would you do this in SVN anyway?  
>  
> Branch commits are inter-twined with trunk commits, and comparing them  
> numerically doesn't yield the results you expect.  

If I give the revision that corresponds to some 3.8 branch commit and compare to another in master, I think I get exactly the result I expect.  
I may not understand your point here...  


>  
> At least in Git, the history is tied up via "parent" and not via  
> sequential IDs, so you can actually walk the path.  
>  
> Sequential numbers are only meaningful for linear histories. Branches,  
> whether on Git or Svn break that promise.  

SVN has monotonic increasing ids that are unique across branches.  


>  
> If we make LNT work with Git "as Git", then all problems are solved.  
> And meanwhile, we get to work with LNT "as SVN" via rev-list --count.  

You missed the point that in a single instance of LNT a revision number has to be unique.  
The rev-list thing won't provide this across branches.  
A rev-list count number won't identify a revision, you need the tuple (branch, count), which is less easy or less compatible with existing systems.  

--  
Mehdi  


>  
> cheers,  
> --renato  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160708/69c1411d/attachment.html>