Over the past couple of weeks, we've become aware of some corner cases in
our logic for caching last commit data for showing the last change to a
file when viewing an SCM tree.  The corner cases are detailed in ticket
#4691 <https://sourceforge.net/p/allura/tickets/4691/>.  In attempting to
come up with a model to handle this efficiently, I've begun to wonder if
it's even possible to do without some manner of walking back up the commit
tree.

The crux of the issue is that any solution that does not include a commit
ID (or at least some sort of revision number) as part of the lookup
criteria will fail on one or more of the corner cases detailed in the
ticket linked above.   (The trickiest one being the case of reverts, in
which the file and tree hashes end up exactly the same and only the
existence and ordering of the commits differentiate the possible
timelines.)  The flip side of this, however, is that including the commit
ID in the lookup criteria for the cache record brings us back to the
original problem which is that we don't know the commit IDs ahead of time
(and attempting to use more abstract but ordered revision numbers still
requires some sort of mapping of revisions to commit IDs).

In the end, I haven't been able to think of a solution, other than brute
force walking back up the commit tree for each file every time we wish to
display it, that doesn't involve (at least at the degenerate case) storing
information about every tree node for every commit, regardless of whether
the tree node was changed.

I was hoping to kick this around on the list here to see if someone smarter
than I could think of a solution, or if a consensus emerges that this may
be premature optimization anyway and that it wouldn't be that expensive to
walk up the tree in the common case anyway.


Thanks,

Cory

-- 
====
This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Reply via email to