Serialize a single Review Request along with necessary objects.
Deserialize a single Review Request from file.
I am currently trying this method. I am using a dictionary to hold uuid-object paired. When an object is deserialized, I put its uuid and its reference into the map. And when establishing FK and m2m relations, I look up the dictionary, find the object represented by the uuid, and get its pk.
One assumption made is that there will be no IntegrityError during deserialiazation. This is not a valid assumption since there can be users with the same user name, or review requests with same unique together fields.
Therefore some extensions of this project it to allow use to change local site name if it's already in use. And detect if a user is trying to import a file once again.
Also I am using an in-memory dictionary to keep uuid to object relations. This works with small amount of review requests. However a permanent storage is needed such as a db, if we are dealing with huge volume of review requests.
I am not exporting file attachment in my json dump.
Tracking branch material (useful for understanding the concepts) -
The current implementation uses git-rev-list, which lists commits that are reachable by following the parent links from the given commit(s), but excludes commits that are reachable from the one(s) given with a ^ in front of them.
You can think of 'git-rev-list' as a set operation. Commits given on the command line form a set of commits that are reachable from any of them, and then commits reachable from any of the ones given with ^in front are subtracted from that set. The remaining commits are what comes out in the command’s output.
Shaurya STests that have been written (from project description)-
Calling delete_branch() with and without the merged_only flag set, ensuring that execute() is called with the right arguments (2 tests). You'll need to use a KGB function spy for this.
Calling create_commit() with the various possible arguments, ensuring that edit_text() is/isn't called (depending) and that execute() is called with the right arguments. Each unique condition should have a test.
Calling merge() with the various possible arguments. Similar to the above. You'll also need to simulate error conditions (which you can do with KGB), and check the resulting exception.
Calling push_upstream() with the various possible arguments, and checking the exceptions in certain cases.
Wrote the following test cases for the following methods of the the GitClient class -
Method name - push_upstream() -
1) Tested push_upstream() with an invalid target branch. The 'git_pull' must raise a PushError exception.
2) Tested push_upstream() with the push_url set to be an invalid one. Neither the 'pull' or the 'push' must raise an exception because it gets it's origin_url from the Git config which still has a valid fetch_url
Method name - merge()
1) Tested merge() with invalid target and destination branches. Both of these must raise a MergeError exception
2) Tested merge() with squash set to True and False. Used a KGB spy to check if execute was called with the right arguments.
Method name - create_commit()
1) Tested create_commit() with run_editor set to True and False. Used a KGB spy to check if edit_text was called or not.
2) Tested create_commit() with all_files set to True and False. Used a KGB spy to check if execute was called with the right arguments.
Method name - delete_branch()
1) Tested delete_branch() with merged_only set to True and False. Used a KGB spy to check if execute was called with the right arguments.
Tests that need to be written (from project description) -
Calling scan_for_server() with a git-svn repository that has a reviewboard:url property on the root of the repository. (You'd need to set this on the SVN repository we have stored inrbtools/clients/testdata/svn-repo), and make sure the result matches.
Start the recording, get your presentation ready, wait a few seconds, and then start talking. When you're done with your presentation, stop talking, wait 5 seconds, then open whatever you need to stop recording. This will let you or us chop off the beginning and end, creating a more clean demo.
Don't assume your audience knows what you're working on! These videos are going up on YouTube, and the viewers may have no idea what your project is about. In each video, briefly talk about what you're building, and don't assume people have watched your prior videos (it's okay to reference them though!) or have read your code.
Name your demo videos as `<UCOSP|OA> Demo Day <number> - <Your Full Name> - <Project Summary>.<ext>`. For example: `UCOSP Demo Day 1 - Christian Hammond - Dinosaurs Everywhere.m4v`.