Reimplement directory diffing for ClearCase and VersionVault.
Review Request #12581 — Created Sept. 6, 2022 and submitted
The community-driven ClearCase implementation included diffs of
directory elements (basically doing a diff of thels
output).
Directory diffs aren't a thing anywhere else in Review Board, but it's
apparently a requirement from our partners at HCL, so we're going to
reimplement this behavior.This change adds back directory diffs, but does so in a hopefully
forward-looking way. We're including the correct "directory" type in the
diffx metadata to indicate that a file entry is actually for a
directory, and we're adding a new key to the VersionVault metadata
section to say that the directory diff is a legacy "filenames" diff.
This will allow us to implement directory diffs in a more useful/correct
way later down the line without having painted ourselves into a corner
relying on only this behavior.I've added unit tests not only for the new directory diffs, but also for
basic file diff generation (in both legacy and diffx mode). While doing
this, I discovered a bug where creating diffs for the legacy mode with
dynamic views would end up replacing filenames twice, resulting in
filenames that looked likevob/vob/file
, instead ofvob/file
. I've
changed it to explicitly replace the old and new filenames only on the
first and second lines of the diff.
- Posted changes including directory diffs (along with a corresponding
Power Pack change) and saw the correct output. - Ran unit tests.
Summary | ID |
---|---|
cf78b149bee7461d73bd10845ae7cce83fd1d07b |
Description | From | Last Updated |
---|---|---|
too many blank lines (2) Column: 9 Error code: E303 |
reviewbot | |
line too long (80 > 79 characters) Column: 80 Error code: E501 |
reviewbot | |
line too long (80 > 79 characters) Column: 80 Error code: E501 |
reviewbot | |
line too long (85 > 79 characters) Column: 80 Error code: E501 |
reviewbot | |
line too long (85 > 79 characters) Column: 80 Error code: E501 |
reviewbot | |
Should be diffx_change. |
chipx86 | |
Something that's come up a lot in my typing work is that the pattern of repurposing a variable to a … |
chipx86 | |
Can we alphabetize the keys? Same above. |
chipx86 | |
Same general issue as above. We're reusing dl for two different types. I'm not sure what we should be calling … |
chipx86 | |
Too many blank lines. |
chipx86 | |
Should return a list of bytes. |
chipx86 | |
I've really liked the approach I'm using for the SOS unit tests, where we have helper functions that let us … |
chipx86 | |
Should be "in diffx mode" instead. |
maubin |
- Commits:
-
Summary ID 14088237e73a4f391f2e43f0c39497b5bcabcb08 72d75e566d2c8bd7df0e39454f2eaf05c60daa06
Checks run (2 succeeded)
-
-
-
Something that's come up a lot in my typing work is that the pattern of repurposing a variable to a new type will no longer be doable.
In this case, the first
revision
can be removed, with theentry.new_version
put inline inrevision = { ... }
.If we need to use a variable elsewhere, we'll need to ensure it has its own name that doesn't get reused under a new type.
-
-
Same general issue as above. We're reusing
dl
for two different types.I'm not sure what we should be calling this, but maybe just
diff
ororig_diff
? -
-
I've really liked the approach I'm using for the SOS unit tests, where we have helper functions that let us output these rules. That keeps the tests readable, and slims down the code. Also has the benefit of letting us do more extensive matching of arguments (
kwargs
) and being easier to update for, say,execute
->run_process
.I'll leave it up to you as to whether to do that for this change. If not, every one of these will have to be redone for the
run_process
migration anyway.