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.am...@apple.com) wrote:
Sent from my iPhone
> On Jul 8, 2016, at 9:18 AM, Renato Golin wrote:
>
>> On 8 July 2016 at 03:14, Robinson, Paul 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
