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).