COMP 2012H Honors Object-Oriented Programming and Data Structures

Assignment 2 Grade Appeal

Introduction

Check the Assignment 2 grade on the ZINC Online Submission System. Your submission record will state all test case failures (if any).

While there are multiple grading records on ZINC, only the latest one will count as the score for your submission; you can ignore other previous records.

Since we did not mention how late penalty is calculated, we gave a grace period of 5 minutes to late submission. Your latest submission before 23 October 2021, 00:04 HKT was graded. If there were no submissions before 23 October 2021, 00:04 HKT, your score will be discarded. This applies to the bonus part as well.

To make an appeal for your grades, please follow the below procedure. Appeals with incomplete information and/or not following the procedure will not be processed:

  1. Read the list of common errors (see below) and carefully understand the test cases and the solution.
  2. No partial credits were given for each test-case.
  3. Send an email to the TA in-charge with the subject header "COMP2012H PA2 Grade Appeal".
  4. State which test-case(s) you wish to appeal (refer to the list in the section below). Clearly state your reasoning for why your code should have passed those test-case(s).
  5. You may propose changes to your source code. Attach your code snippet with the proposed changes in your email. However, such changes are subject to a grade deduction at the discretion of the TA in-charge, proportional to the magnitude of change, with a 3% deduction being the minimum.
  6. DO NOT attach any .exe/executable file(s) in your email since we do not run your code outside ZINC.
  7. Appeal deadline is 5 November 2021 Friday 23:59 HKT. No late appeals will be processed.
  8. Finalized scores will be uploaded to Canvas after all appeals are processed.

Your appeal will be processed slowly. Please be patient. If you do not receive any reply or acknowledgment after 72 hours, please send the email again.

Below is a list of common errors and situations for COMP2012H assignments in general:

  • Uninitialized variables will have garbage (random) values in C++. Sometimes it will be 0, sometimes it will not. In that case, your program may generate different results on different machines or different runs if your logic depend on an uninitialized value. If you have assumed them to be 0 or something specific (e.g. a very large value), your code is faulty and will get random results.
  • Retrieving values from deleted/unallocated dynamic memory, or index out-of-bounds, may not always crash your program but may give random values.
  • Compilation errors will result in 0 marks for this assignment. This should not occur as revealed test cases were already provided to test your code on ZINC. Exceptions will only be given for compilation errors that are the fault of the TA's testing code.
  • Runtime errors and crashes due to incorrect memory access, memory allocation, memory deallocation, missing variable initialization, missing return values, out-of-bound array access, etc. may not occur all the time on all machines. However, even though you may not encounter the error/crash when you test your program, if your program crashes during any of the test cases on ZINC, the corresponding test cases will be considered as incorrect and will receive 0 marks.
  • Runtime crashes due to the reasons above or due to timeouts (infinite loop / infinite recursion / runtime taking too long) will only be regraded if you can debug, fix, and report it in your email appeal with attached code snippet. The corresponding test-case(s) where the runtime crash occurred will still be considered as incorrect and will receive 0 marks, but you can recover your marks for the rest of the test-cases.

End of Introduction

Resources

Notes for grading package:
  • The main difference of Gitlite of the grading package compared to the one you obtained from the skeleton code is that all filesystem operations are replaced by in-memory operations (See FilesystemStub.cpp).
  • To test it with your submission, extract this zip and copy your Commit.cpp and gitlite.cpp to this directory. Then run make: 
    
                    make
    Two executables are produced:
    • gitlite-grader: The grader version of Gitlite with all filesystem operations replaced by in-memory operations.
    • gitlite-unit-testing: Unit testing cases of individiual functions.
  • In this version, you need to run the test cases one-by-one (batch running is not available). For example, 
    
                    # For Windows
                    .\gitlite-grader -t tests/init.in

                    # For macOS and Linux
                    ./gitlite-grader -t tests/init.in
  • To run memory leak check, use this Makefile and follow the instructions here. The Makefile produces two additional executables:
    • gitlite-grader-leak: The grader version of Gitlite with all filesystem operations replaced by in-memory operations. Also runs GCC sanitizer.
    • gitlite-unit-testing-leak: Unit testing cases of individiual functions. Also runs GCC sanitizer.
End of Resources

Unit Testing (50+4 points)

The following test cases of unit testing correspond to those listed in ZINC. You can run them by providing the test case number to gitlite-unit-testing. For example, this runs test case 10: 


                  # For macOS and Linux
                  ./gitlite-unit-testing 10

                  # For Windows
                  ..\gitlite-unit-testing.exe 10

Part 1: Linked List Operations (20 points)

  1. [0.5 points] ListNew: Calls list_new() to create a list. The data fields in the sentinel are checked.
  2. [1 point] ListPushBackOne: Calls list_push_back() to add one blob at the back. Both forward and backward orders of the linked list are checked.
  3. [1 point] ListPushBackMultiple: Calls list_push_back() to add multiple blobs at the back. Both forward and backward orders of the linked list are checked.
  4. [1 point] ListFindNameFound: Calls list_find_name() to find a blob with the given name. The blob can be found. The return values are checked.
  5. [1 point] ListFindNameNotFound: Calls list_find_name() to find a blob with the given name. The blob cannot be found. The return values are checked.
  6. [0.5 points] ListPutNewOne: Calls list_put() to add a blob to the list. The return value is checked. Both forward and backward orders of the linked list are checked.
  7. [0.5 points] ListPutNewMultiple: Calls list_put() to add multiple blobs to the list. The return values are checked. Both forward and backward orders of the linked list are checked.
  8. [0.5 points] ListPutUpdateOne: Calls list_put() to update a blob in the list. The return value is checked. Both forward and backward orders of the linked list are checked.
  9. [0.5 points] ListPutUpdateMultiple: Calls list_put() to update multiple blobs to the list. The return values are checked. Both forward and backward orders of the linked list are checked.
  10. [0.5 points] ListPutNewMultipleCommit: Same as ListPutNewMultiple but uses commits instead.
  11. [0.5 points] ListPutUpdateMultipleCommit: Same as ListPutUpdateMultiple but uses commits instead.
  12. [0.5 points] ListRemoveNotFound: Calls list_remove() to remove a blob with the given name. The blob cannot be found. The return values are checked. Both forward and backward orders of the linked list are checked.
  13. [0.5 points] ListRemoveOne: Calls list_remove() to remove a blob with the given name. The blob can be found and removed. The return value is checked. Both forward and backward orders of the linked list are checked.
  14. [1 point] ListRemoveAll: Calls list_remove() to remove all blobs from the list. The return values are checked. Both forward and backward orders of the linked list are checked.
  15. [0.5 points] ListSize: Calls list_size() to get the size of several lists.
  16. [1 point] ListClearEmpty: Calls list_clear() on an empty list. Both forward and backward orders of the linked list are checked.
  17. [1 point] ListClearNonEmpty: Calls list_clear() on an non-empty list. Both forward and backward orders of the linked list are checked.
  18. [0.5 points] ListReplaceEmptyByEmpty: Calls list_replace() to replace an empty list by an empty list. Both forward and backward orders of the linked list are checked.
  19. [0.5 points] ListReplaceEmptyByNonEmpty: Calls list_replace() to replace an empty list by an non-empty list. Both forward and backward orders of the linked list are checked.
  20. [0.5 points] ListReplaceNonEmptyByEmpty: Calls list_replace() to replace an non-empty list by an empty list. Both forward and backward orders of the linked list are checked.
  21. [0.5 points] ListReplaceNonEmptyByNonEmpty: Calls list_replace() to replace an non-empty list by an non-empty list. Both forward and backward orders of the linked list are checked.
  22. [1 point] ListCopyEmpty: Calls list_copy() to copy an empty list. Both forward and backward orders of the linked list are checked.
  23. [1 point] ListCopyNonEmpty: Calls list_copy() to copy an non-empty list. Both forward and backward orders of the linked list are checked.
  24. [1 point] ListDeleteEmpty: Calls list_delete() on an empty list.
  25. [0.5 points] ListDeleteNonEmpty: Calls list_delete() on non-empty list.
  26. [0.5 points] ListDeleteEmptyCommit: Same as ListDeleteNonEmpty but the list contains branches that have a commit pointer.
Memory Leak Check

The following test cases also run GCC sanitizer to check for memory leak.

  1. [1 point] Same as test case 24.
  2. [0.5 points] Same as test case 25.
  3. [0.5 points] Same as test case 26.

Part 2: Gitlite Commands (30 points)

  1. [1.5 points] Init: Calls init() and verifies the data structures.
  2. [1 point] AddUntrackedFiles: Calls add() to add untracked files.
  3. [1 point] AddUpdatedFiles: Calls add() to add a tracked file with updated content.
  4. [1 point] AddUnchangedFiles: Calls add() to add a tracked file with unchanged content.
  5. [1 point] AddRemovedFiles: Calls add() to add a file that is staged for removal.
  6. [1 point] CommitWithChanges: Calls commit() to make a commit with files staged for addition.
  7. [0.5 points] CommitWithoutChanges: Calls commit() to make a commit without files staged for addition and removal.
  8. [1 point] CommitWithRemovalOnly: Calls commit() to make a commit with files staged for removal only.
  9. [1 point] RemoveStagedFiles: Calls remove() to remove a file that is staged for addition.
  10. [1 point] RemoveHeadTrackedFiles: Calls remove() to remove a file that is tracked in the head commit of the repository.
  11. [0.5 points] RemoveFilesNotExist: Calls remove() to remove a file that is neither staged for addition nor tracked in the head commit of the repository.
  12. [1 point] CheckoutFiles: Calls checkout() to checkout files from different commits.
  13. [0.5 points] CheckoutFilesNotExist: Calls checkout() to checkout files that do not exist in commits.
  14. [0.5 points] CheckoutCommitNotExist: Calls checkout() to checkout files from commits that do not exist.
  15. [1.5 points] CheckoutBranch: Calls checkout() to checkout a branch.
  16. [0.5 points] CheckoutBranchNotExists: Calls checkout() to checkout a branch that does not exist.
  17. [0.5 points] CheckoutCurrentBranch: Calls checkout() to checkout the current branch.
  18. [0.5 points] ResetToParent: Calls reset() to reset to the parent commit.
  19. [1 point] ResetToSelf: Calls reset() to reset to the head commit of the repository.
  20. [0.5 points] ResetToCommitNotExists: Calls reset() to reset to a commit that does not exist.
  21. [0.5 points] CreateNewBranch: Calls branch() to create a new branch.
  22. [0.5 points] CreateBranchWithDuplicateName: Calls branch() to create a branch with existing name.
  23. [0.5 points] RemoveBranch: Calls remove_branch() to remove a branch.
  24. [0.5 points] RemoveBranchNotExists: Calls remove_branch() to remove a branch that does not exist.
  25. [0.5 points] RemoveCurrentBranch: Calls remove_branch() to remove the current branch.
  26. [1 point] MergeAncestors: Calls merge() to merge an ancestor into the current branch.
  27. [1 point] MergeHandlesFastForwading: Calls merge() to merge a branch with fast forward.
  28. [1 point] MergeOverwritingUntrackedFiles: Calls merge() to merge a branch that would overwrite untracked files.
  29. [0.5 point] MergeGeneralTest: Calls merge() to merge a branch into the current branch.
  30. [0.5 point] MergeBranchNotExists: Calls merge() to merge a branch that does not exist.
  31. [0.5 point] MergeCurrentBranch: Calls merge() to merge the current branch.
  32. [0.5 point] MergeWithUncommitedChanges: Calls merge() with uncommitted changes.
The following test cases test get_lca()
  1. [0.5 points] Same: Calls get_lca() with two identical commits.
  2. [0.5 points] Ahead: Calls get_lca() with one commit is ahead of another.
  3. [0.5 points] Diverged: Calls get_lca() with two commits whose history have diverged.
Memory Leak Check

The following test cases also run GCC sanitizer to check for memory leak.

  1. [0.5 points] Same as test case 27.
  2. [0.5 points] Same as test case 41.
  3. [0.5 points] Same as test case 44.
  4. [0.5 points] Same as test case 47.
  5. [0.5 points] Same as test case 49.
  6. [0.5 points] Same as test case 55.
  7. [0.5 points] Same as test case 60.
  8. [0.5 points] Same as test case 61.

Bonus (4 points)

  1. [1 point] Merged1: Calls get_lca() where the commit history contains second parent.
  2. [1 point] Calls get_lca() where the commit history contains second parent.
  3. [1 point] Same as test case 62 also runs GCC sanitizer to check for memory leak.
  4. [1 point] Same as test case 63 also runs GCC sanitizer to check for memory leak.
End of Unit Testing

Integrated Testing (50+6 points)

The following test cases run the automated testing module of Gitlite, with all filesystem operations replaced by in-memory operations. You can read the content of the files used in auto-testing/src.

To run the integrated testcases, first change the working directory to auto-testing. If you are using VSCode, right click on auto-testing in the directory structure that appears on the left, click "Open in Integrated Terminal". Run the grading version of Gitlite, which is located in the parent directoy in the following way (this example runs the test case init.in): 


                # For macOS and Linux
                ../gitlite-grader -t tests/init.in

                # For Windows
                ..\gitlite-grader.exe -t tests\init.in

You can read and understand the test cases in order to know what commands were being tested and the expected output.

  1. [2 points] init.in
  2. [2 points] add-multi.in
  3. [2 points] add-remove.in
  4. [2 points] commit.in
  5. [2 points] rm.in
  6. [2 points] checkout-file.in
  7. [3 points] checkout-branch.in
  8. [3 points] reset.in
  9. [4 points] merge-simple.in
  10. [2 points] merge-case123.in
  11. [1 points] merge-case45.in
  12. [1 points] merge-case67.in
  13. [1 points] merge-case8a.in
  14. [2 points] merge-case8b.in
  15. [1 points] merge-case8c.in
  16. [3 points] merge-case-all.in
  17. [4 points] branch-and-rm.in
  18. [2 points] log.in
  19. [2 points] status-branch.in
  20. [5 points] status-files.in
Memory Leak Check

The following test cases also run GCC sanitizer to check for memory leak.

  1. [1 point] Same as test case 70.
  2. [1 point] Same as test case 71.
  3. [1 point] Same as test case 79.
  4. [1 point] Same as test case 83.

Bonus (6 points)

  1. [5 points] merge-2nd-parent.in
  2. [1 point] Same as test case 84 also runs GCC sanitizer to check for memory leak.
End of Integrated Testing
Menu
Page maintained by
Homepage