p4hl.dll #1

#	Change	User	Description
#1	7292	Andrew McDonald	initial submittal
//guest/sam_stafford/p4hl/dist/dlls/p4hl.dll
#28	1797	Sam Stafford	Fix a permissions-related crashing bug.
#27	1562	Sam Stafford	Latest DLL build - the previous one might be bug-riddled, not sure. Just being safe.
#26	1549	Sam Stafford	Quick tweak to ObjectRev to make sure it's compatible with new RevType structure. No functional change.
#25	1457	Sam Stafford	Use RunTag() to queue up filelog commands. Should in theory improve performance, although I haven't noticed any great difference. Integration only change.
#24	1452	Sam Stafford	Fix nasty flickering bug introduced by FileRevArrow conversion in a stupid attempt to compensate for the flickering I was seeing as a result of duplicate pointers (in reality, I only made things worse!). Lesson learned is to avoid drawing lasers overlapping each other, which means making the length of time the laser stays on equal to the time between activations if at all possible.
#23	1450	Sam Stafford	Major performance improvement - use one ClientApi connection for all filelogs. Improves querying time about tenfold on large requests! Had to move client->Final() to the constructor to ensure that connection is cleaned up promptly and doesn't hang things up.
#22	1433	Sam Stafford	Integ display: if you see one of a file's revisions, you see them all. Previously, your view was limited to those revisions which were directly related to the file you asked about. However, if you asked about a file branched from the mainline, this meant that you couldn't see mainline changes that weren't yet integrated into your branch, and that's not terribly useful.
#21	1431	Sam Stafford	Fixed bug with "weight" ("contrib" attribute) of white beams being drawn incorrectly - I'd confused myself when I was adding them to FileHead::addRev(). All better now.
#20	1422	Sam Stafford	Fixed a major crashing bug related to trying to draw relationships to filerevs that weren't being drawn themselves (access violation). Three line fix for a problem that took three days to find. facepalm
#19	1405	Sam Stafford	Phew - this was a big one! New functionality: The rare case in which a revision has multiple parents, due to multiple resolves before submit, is now handled properly. There is no limit on the number of "parents" a revision may have. Integration lines are now always "weighted" to indicate whether they contributed all, some, or none to the target. For example, a "branch" line will be very solid and wide, whereas an "ignore" will be thin and faint. Rearchitecture: Now using low-cost structs to keep track of integration information. Also being just a little more efficient with scanning through large data structures. Quite a bit of general code bloat trimmed off now that some of the kludges are gone. Possible problems: Not sure yet, but it might happen that "duplicate" integration pointers will be created, now that it's not a single variable which would get overwritten in the event of a duplicate. to-do: Trim off obsolete member variables. Use more enums and fewer #defs.
#18	1349	Sam Stafford	Overhaul to ChangeSorter implementation. Member variables of ChangeSorter have been made private, since nothing was (or should be) accessing them directly, and methods, which remain public, should look the same from outside. The original ChangeSorter was quick and dirty because I wanted to see P4HL working quickly, but it was also about as inefficient as possible because it used single links and linear searches. The new and improved ChangeSorter is a doubly-linked list with intelligent searching that's geared toward sequential access of elements that are close to each other, which is indeed the nature of most of the queries that P4HL makes. Even in a worst-case scenario, this version should perform at least as well as the old one. No noticeable performance change or bugs as of yet, but in theory we'd see the difference with really large sets of data (ones larger than P4HL can show us).
#17	1047	Sam Stafford	Ensure that the pointer-setting step is carried out even if the "into" section in the cache is empty. (Bug introduced by change 1024.)
#16	1024	Sam Stafford	Reworked entity creation in most cases - it's done one at a time now rather than all at once. This allows us to have more entities than the previous limit of 130, and also looks a little nicer. Folders and files now pop into existence instantly instead of sliding - makes navigation easier. Depots still slide because there typically aren't as many of them (okay, I might eventually make them pop too, but I'm tired now). Revisions slide because it looks really cool - like a waterfall pouring out of the file. The upper limit to entities is now due to the "visible entity packet" thing, which I'm certain I have no control over - it's as high as it can possibly be right now.
#15	1008	Sam Stafford	Fixed a bug with the whole "istext" thing - wasn't setting the bit on CObjectRevs other than "main", so they'd all default to false. Now it seems to be better. Also cleaned up the style a little bit by including istext in the constructors, rather than setting it after construction.
#14	1007	Sam Stafford	A stab at making P4HL a bit more accessible to Perforce novices. During the Precache() phase of the P4HL objects, a "p4 info" is executed. If this returns any errors, odds are there's no server there (I can't think of what other error "p4 info" would return). If this happens, use "public.perforce.com:1666" as the new port value for all future Perforce transactions during this session, and send a message to the console explaining this.
#13	1006	Sam Stafford	Lower the height of the "main" revision list so it doesn't look quite so weird. Delete a few unnecessary WAD files.
#12	1004	Sam Stafford	Different file types are now treated differently - the ObjectFiles have different skins depending on file type of the head rev, and non-text revisions will not attempt to display their contents when expanded. Possible bug: old-style filetypes might be detected wrong (ie "ktext" instead of "text+k"). I'd have to put in some pretty complex logic to make it completely foolproof and backwards-compatible. Right now it just errs on the side of thinking a file is text if there's any confusion.
#11	993	Sam Stafford	Improvements to integ pointer display : 1) Integ pointers not drawn until both revs have stopped moving. 2) "Branch" type pointers always drawn if target is a "branch" rev.
#10	992	Sam Stafford	Make sure that any "branch" type revisions are properly marked with a "branch" type integ pointer. In some cases, apparently, the filelog doesn't include that information properly, in which case the integration looks like the default "merge". Not sure why; this phenomenon was observed in the Public Depot. Presumbably it's some kind of artifact of an older server version.
#9	991	Sam Stafford	Tweaks to display of ObjectRevs: 1) Random variation in their height. This is intended to make overlapping lasers less common. 2) The "main" revisions are now connected by brighter white beams in order to make it obvious which file is the one we asked about.
#8	986	Sam Stafford	If no depots are listed by "p4 depots", assume that there is one depot called "depot".
#7	981	Sam Stafford	scanFrom and scanInto modified to use the "precaching" technique. All of the tests I've run so far with this code have yielded very comprehensible graphs, and performance is still very speedy. This should be the final fix for job 4.
#6	975	Sam Stafford	Nigh-complete fix for job 4 - the "scan" methods all go from tail to head now, and Get uses the improved "addAfter" method where appropriate. An unforeseen problem was the fact that a complex integ history can get followed through more than one possible path, causing later versions of a given file to get scanned before earlier versions, and messing up the graph. This is fixed (albeit in a kludgey fashion) in scanMain here by making two passes through the FileHead, caching the files on the first pass and actually running scans on the second pass. A slightly more efficient way of handling it might be to keep a list of FileRevs that need to be scanned - perhaps by declaring a temporary FileHead to serve as a list? Once it's been hammered out in scanMain() satisfactorily that method can be employed in the other scan methods.
#5	974	Sam Stafford	Partial fixes to the sorting of a FileLogCache as it's created. FileRevs are now doubly-linked. FileHead now has a scanMain() function that acts as an interleaved scanFrom and scanInto. The next step will be to have scans go from #1 to #head (this is why FileRevs are now doubly linked).
#4	971	Sam Stafford	Have the ObjectInfo run a "p4 info" every 30 seconds.
#3	958	Sam Stafford	Fixed another bug found at the 2001 Conference. This was one with integ pointers not being drawn correctly. It turned out to be a mistake in FileHead::scanInto. If the "intocheck" bit was set, the rev would be skipped over. In most cases this is fine, but what if the previous scanInto sweep on that rev wasn't sent by the rev's integ parent? In that case, when the integ parent calls scanInto on that rev, it gets ignored because it looks like scanInto has already done its work there. The fix was one line: when skipping over an intocheck'd rev, if it's the startrev, make sure the from pointer is set. (There may be an analogous bug in scanFrom - will have to check.) (Update: No such bug in scanFrom.)
#2	957	Sam Stafford	Make CObjectFile::Expand ignore FileRevs that don't have "fromcheck" or "intocheck" flagged.
#1	937	Sam Stafford	Renaming my guest directory to the more conventional sam_stafford.
//guest/samwise/p4hl/dist/dlls/p4hl.dll
#1	936	Sam Stafford	Adding P4HL to the public depot. See relnotes.txt for installation instructions; all relevant files are under p4hl/dist. Source code is under p4hl/src in the form of a VC++ project.