• 
      

    Implement submitted changeset posting for Perforce.

    Review Request #5196 — Created Jan. 5, 2014 and submitted

    Information

    RBTools
    master
    921

    Reviewers

    Implement submitted changeset posting for Perforce.

    This change implements posting for submitted changesets in Perforce. In order
    to do this, we fetch the filelog between those revisions, which will give us a
    list of every change to every file within those revisions. This is then
    processed to accumulate changes together. At the end of this, for each file,
    we'll have one of four operations: add, delete, edit, or move. Move operations
    can also include edits. This is a little bit complicated to track moves within
    the revision range. Just diffing the two trees would handle adds, deletes, and
    edits, but not moved files.

    • Ran unit tests
    • Posted a variety of revision range changes which included all four of the
      overall change types.
    Description From Last Updated

    No need for the outer parens.

    chipx86chipx86

    """ on the next line.

    chipx86chipx86

    I know we do this elsewhere, but given that file is a reserved word, we should use filename or something.

    chipx86chipx86

    We should catch and make sure any issues here are at least logged.

    chipx86chipx86

    Can we define this on the class so we don't end up building this list every iteration?

    chipx86chipx86

    Same comment here about catching errors.

    chipx86chipx86

    You can use setdefault here instead.

    chipx86chipx86

    Given that this function doesn't seem to depend on anything in the parent scope, can we move it into its …

    chipx86chipx86

    I'm hoping we can work toward getting rid of die, since it's not exactly safe when called from anything but …

    chipx86chipx86

    Can we raise an exception here?

    chipx86chipx86

    Just realized, this will break on Python 2.4. You can't use super with exceptions.

    chipx86chipx86
    chipx86
    1. 
        
    2. rbtools/clients/perforce.py (Diff revision 1)
       
       
       
       

      Are integrate and branch no longer used at any point?

      1. Didn't mean to do this.

    3. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      No need for the outer parens.

    4. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      """ on the next line.

    5. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      I know we do this elsewhere, but given that file is a reserved word, we should use filename or something.

    6. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      We should catch and make sure any issues here are at least logged.

    7. rbtools/clients/perforce.py (Diff revision 1)
       
       
       
      Show all issues

      Can we define this on the class so we don't end up building this list every iteration?

      1. How is it building the list every iteration? The literal isn't re-parsed for each iteration of the loop.

      2. Didn't consider that it just treated it as a literal. You're right.

        I ran a test to see just what the difference would be, for my own curiosity. I created two scripts with a simple loop doing an if like above, one with the list inline and one pre-defined. It looped it 50 million times, and the literal was faster by 1.4 seconds.

        The more you know.

    8. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      Same comment here about catching errors.

    9. rbtools/clients/perforce.py (Diff revision 1)
       
       
       
       
       
      Show all issues

      You can use setdefault here instead.

      1. I'm not sure I understand how that would apply in this situation.

      2. changesets.setdefault(cln, {}).set('depot_file', change)

        No big deal, just figured it'd save a couple lines.

    10. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      Given that this function doesn't seem to depend on anything in the parent scope, can we move it into its own proper method on the class? The parent function's pretty large as it is.

    11. rbtools/clients/perforce.py (Diff revision 1)
       
       
       
       

      Do we want to break when we find this, or go for the last one?

    12. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      I'm hoping we can work toward getting rid of die, since it's not exactly safe when called from anything but an RBTools command. Can we raise exceptions instead?

      There was another somewhere else as well that this also applies to.

      1. I'll fix the one I'm adding but I don't want to make more, unrelated changes right now.

      2. Completely fine.

    13. rbtools/clients/perforce.py (Diff revision 1)
       
       
      Show all issues

      Can we raise an exception here?

      1. AssertionError? :P

        This really is a code consistency check and not really logic. The various tests in the if/elif/else clause are all data that is just used internally.

        That said, looking at this, I did forget to handle a few cases :P

      2. Sure, that's fine.

    14. 
        
    david
    chipx86
    1. 
        
    2. rbtools/clients/errors.py (Diff revision 2)
       
       
       
       
       
       
       
       
       
      Show all issues

      Just realized, this will break on Python 2.4. You can't use super with exceptions.

      1. Can we bump up to 2.5 for rbtools 0.6? 2.5 is over 7 years old now.

    3. 
        
    david
    chipx86
    1. Ship It!
    2. 
        
    david
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to master (9ba6c27).