Add support for VersionVault

Review Request #11582 — Created April 7, 2021 and submitted

Information

RBTools
master

Reviewers

We will soon be adding a new SCMTool implementation to Power Pack to connect to
HCL VersionVault and IBM ClearCase, supplanting the old community-driven
ClearCase support. This change adds RBTools-side support for this.

This is based on code delivered to us in partnership with HCL, but has had
significant changes. The largest change is that instead of having a completely
separate SCMClient implementation in RBTools, this is built into the same
ClearCase client. Most of the code paths are the same between the two types of
backends, and the major difference is that the diff output for VersionVault
includes additional information in the headers (the VOB OID for each changed
element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order
to do better post-processing on the diff display).

There's still more to do for unit testing but functionality should be
relatively complete at this point.

  • Posted changes from the current checkout (rbt post with no args) including
    new, modified, deleted, renamed, and binary files.
  • Posted changes that spanned multiple VOBs.
  • Posted a change that spanned multiple VOBs, including one that was not
    configured as part of the server-side repository. Saw expected
    warning.
  • Posted changes for UCM activities for both a single and multiple
    revisions.
  • Ran unit tests.
Summary ID
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still more to do for unit testing but functionality should be relatively complete at this point. Testing Done: - Posted changes from the current checkout (rbt post with no args) including new, modified, deleted, renamed, and binary files. - Posted changes that spanned multiple VOBs. - Posted a change that spanned multiple VOBs, including one that was not configured as part of the server-side repository. Saw expected warning. - Posted changes for UCM activities for both a single and multiple revisions. - Ran unit tests.
59075254cdddca197daf45ba385804472eb78471
Description From Last Updated

E501 line too long (81 > 79 characters)

reviewbotreviewbot

E722 do not use bare except'

reviewbotreviewbot

, optional?

chipx86chipx86

F401 'rbtools.api.errors.AuthorizationError' imported but unused

reviewbotreviewbot

Blank line after class docstring.

chipx86chipx86

These are so close. Can we build up the cmdline based on self.label and then pass in to execute()?

chipx86chipx86

Should be is_ucm.

chipx86chipx86

Can you specify explicitly which is which?

chipx86chipx86

Can you update this to point to the full class path?

chipx86chipx86

E501 line too long (81 > 79 characters)

reviewbotreviewbot

I think we can just use os.pathsep for this, which is for things like $PATH. Same with the earlier usage …

chipx86chipx86

Is Qp part of this?

chipx86chipx86

These are pretty close. Can we build up a cmdline and then pass it to execute()?

chipx86chipx86

F821 undefined name 're'

reviewbotreviewbot

Let's compile the regex right before and then reuse that. I don't think we need the [ and ] though.

chipx86chipx86

You can pass a tuple of choices here.

chipx86chipx86

You can use os.pathsep here too. Kinda wonder if we should predefine constants for the environment variables on the class …

chipx86chipx86

Given how simple this logic is, how about just: if label != 'LATEST' and not self._is_a_label(label, tag): labels_present = False

chipx86chipx86

Small nit, but mind alphabetizing these? We also build the string twice. Might as well do it once and then …

chipx86chipx86

We can just pass split_lines=True to execute().

chipx86chipx86

F821 undefined name 're'

reviewbotreviewbot

Just to check, are we splitting on \s, :, or @? Or on \s:@? The [] will give us the …

chipx86chipx86

Instead of setting twice, maybe have the second do: extra_data['new'] = extra_data['old'].copy()

chipx86chipx86

No need for , None on these.

chipx86chipx86

E722 do not use bare except'

reviewbotreviewbot

E201 whitespace after '{'

reviewbotreviewbot

E202 whitespace before '}'

reviewbotreviewbot

E272 multiple spaces before keyword

reviewbotreviewbot

E272 multiple spaces before keyword

reviewbotreviewbot

F841 local variable 'CLEARCASE_PN' is assigned to but never used

reviewbotreviewbot

F841 local variable 'commmand' is assigned to but never used

reviewbotreviewbot

F821 undefined name 'command'

reviewbotreviewbot

E501 line too long (91 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (109 > 79 characters)

reviewbotreviewbot

E501 line too long (107 > 79 characters)

reviewbotreviewbot

E501 line too long (115 > 79 characters)

reviewbotreviewbot

E201 whitespace after '{'

reviewbotreviewbot

E202 whitespace before '}'

reviewbotreviewbot

E501 line too long (91 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (107 > 79 characters)

reviewbotreviewbot

E201 whitespace after '{'

reviewbotreviewbot

E202 whitespace before '}'

reviewbotreviewbot

F811 redefinition of unused 'test_get_repository_info_dynamic' from line 107

reviewbotreviewbot

E501 line too long (84 > 79 characters)

reviewbotreviewbot

E501 line too long (91 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (107 > 79 characters)

reviewbotreviewbot

E201 whitespace after '{'

reviewbotreviewbot

E202 whitespace before '}'

reviewbotreviewbot

E501 line too long (84 > 79 characters)

reviewbotreviewbot

E501 line too long (91 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (97 > 79 characters)

reviewbotreviewbot

E501 line too long (107 > 79 characters)

reviewbotreviewbot

E131 continuation line unaligned for hanging indent

reviewbotreviewbot

E201 whitespace after '{'

reviewbotreviewbot

E202 whitespace before '}'

reviewbotreviewbot

Probably should be , optional.

chipx86chipx86

The common part was split out, but these are overriding instead of appending to it.

chipx86chipx86

No blank line here.

chipx86chipx86

Typo: "becaue" -> "because"

chipx86chipx86

To ensure doc building works right, the format: should be format::. This will turn this into a code block.

chipx86chipx86

I have no idea if it's faster or not, but we can probably just have this be: if '%s/' % …

chipx86chipx86

Is "base clearcase" correct? Drawing a blank on the term. Is this just IBM ClearCase?

chipx86chipx86

Can we update these to use the formal capitalization of these names?

chipx86chipx86

Small nit: Alphabetical order?

chipx86chipx86

E303 too many blank lines (2)

reviewbotreviewbot

E501 line too long (89 > 79 characters)

reviewbotreviewbot

F401 'json' imported but unused

reviewbotreviewbot

E501 line too long (80 > 79 characters)

reviewbotreviewbot

E501 line too long (81 > 79 characters)

reviewbotreviewbot

E501 line too long (80 > 79 characters)

reviewbotreviewbot

E501 line too long (81 > 79 characters)

reviewbotreviewbot

F841 local variable 'diffx_file' is assigned to but never used

reviewbotreviewbot

F841 local variable 'file_split_re' is assigned to but never used

reviewbotreviewbot

E501 line too long (81 > 79 characters)

reviewbotreviewbot

E501 line too long (81 > 79 characters)

reviewbotreviewbot

Given how old this is, let's nuke it and instead put 3.0, and mention the new support.

chipx86chipx86

Definitions generally go at the bottom of the section (the rest of our docs do this).

chipx86chipx86

The "3.0" has to be on the next line for section parsing to consider this correctly.

chipx86chipx86

Can you add "Version Added"?

chipx86chipx86

I don't know what's really correct, but historically we've put __init__ before @properties. We should probably err on the side …

chipx86chipx86

Minor thing, but should these have quotes around the examples?

chipx86chipx86

Maybe double backticks around teh <...> bits?

chipx86chipx86

"a was removed" -> "was removed"

chipx86chipx86

This isn't true anymore, right? Given the docs in the function.

chipx86chipx86

Is there supposed to be a trailing comma on -predecessor?

chipx86chipx86

Can we maek this a standard private function? I feel like this doesn't really need to be inline like this.

chipx86chipx86

These could be combined.

chipx86chipx86

"Return ..." better describes what this is doing.

chipx86chipx86

Given that we never really need i, this can probably just be a standard for f in files.

chipx86chipx86

Same as above.

chipx86chipx86

Same as above.

chipx86chipx86

This is repeated a lot. How about building the base command line outside the loop, then just do cmdline + …

chipx86chipx86

Just to check, is the extra space on the 3rd line here intentional? It shows up on the other examples …

chipx86chipx86

E265 block comment should start with '# '

reviewbotreviewbot

F821 undefined name '_get_content_snapshot'

reviewbotreviewbot

F821 undefined name '_get_content_snapshot'

reviewbotreviewbot

E303 too many blank lines (2)

reviewbotreviewbot

F821 undefined name 'i'

reviewbotreviewbot
Checks run (1 failed, 1 succeeded)
flake8 failed.
JSHint passed.

flake8

david
Review request changed

Summary:

-WIP integrating ClearCase/VersionVault
+[WIP] Add support for VersionVault

Description:

~  

WIP integrating ClearCase/VersionVault

  ~

We will soon be adding a new SCMTool implementation to Power Pack to connect to

  + HCL VersionVault and IBM ClearCase, supplanting the old community-driven
  + ClearCase support. This change adds RBTools-side support for this.

  +
  +

This is based on code delivered to us in partnership with HCL, but has had

  + significant changes. The largest change is that instead of having a completely
  + separate SCMClient implementation in RBTools, this is built into the same
  + ClearCase client. Most of the code paths are the same between the two types of
  + backends, and the major difference is that the diff output for VersionVault
  + includes additional information in the headers (the VOB OID for each changed
  + element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order
  + to do better post-processing on the diff display).

  +
  +

There's still significant testing (manual and automatic) and documentation work

  + to do on this, hence the WIP.

Commits:

Summary ID
WIP integrating ClearCase/VersionVault
21e833e925330f4744519f9589a302558eb1c157
[WIP] Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still significant testing (manual and automatic) and documentation work to do on this, hence the WIP.
10b83aad42568cb813f7e55e9f64c0224e329945

Diff:

Revision 2 (+1452 -452)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

chipx86
  1. 
      
  2. rbtools/clients/__init__.py (Diff revision 2)
     
     
    Show all issues

    , optional?

  3. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
    Show all issues

    Blank line after class docstring.

  4. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Show all issues

    These are so close. Can we build up the cmdline based on self.label and then pass in to execute()?

  5. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    Should be is_ucm.

  6. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
     
    Show all issues

    Can you specify explicitly which is which?

  7. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    Can you update this to point to the full class path?

  8. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
    Show all issues

    I think we can just use os.pathsep for this, which is for things like $PATH.

    Same with the earlier usage as well.

    1. I suppose it's possible that would work, but I think this handles the common case of cygwin, where os.pathsep is ":" but cleartool will be expecting ";".

  9. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    Is Qp part of this?

    1. That's part of the code we got from HCL. I'm not 100% sure one way or the other yet, since my UCM knowledge is still pretty spare.

    2. Answer: Qp is part of it.

  10. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Show all issues

    These are pretty close. Can we build up a cmdline and then pass it to execute()?

  11. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    Let's compile the regex right before and then reuse that.

    I don't think we need the [ and ] though.

  12. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    You can pass a tuple of choices here.

  13. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
    Show all issues

    You can use os.pathsep here too.

    Kinda wonder if we should predefine constants for the environment variables on the class on first use or something, cut down on the conditionals further. Super not important, but just a food-for-thought thing.

  14. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
     
    Show all issues

    Given how simple this logic is, how about just:

    if label != 'LATEST' and not self._is_a_label(label, tag):
        labels_present = False
    
  15. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
    Show all issues

    Small nit, but mind alphabetizing these?

    We also build the string twice. Might as well do it once and then set.

  16. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
     
    Show all issues

    We can just pass split_lines=True to execute().

  17. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    Just to check, are we splitting on \s, :, or @? Or on \s:@? The [] will give us the former.

    1. I don't know the answer to this yet.

  18. rbtools/clients/clearcase.py (Diff revision 2)
     
     
     
     
     
     
     
     
     
    Show all issues

    Instead of setting twice, maybe have the second do:

    extra_data['new'] = extra_data['old'].copy()
    
    1. These aren't the same.

  19. rbtools/clients/clearcase.py (Diff revision 2)
     
     
    Show all issues

    No need for , None on these.

  20. 
      
david
Review request changed

Change Summary:

Continued progress

Commits:

Summary ID
[WIP] Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still significant testing (manual and automatic) and documentation work to do on this, hence the WIP.
10b83aad42568cb813f7e55e9f64c0224e329945
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still significant testing (manual and automatic) and documentation work to do on this, hence the WIP.
e31e376b3d67b0c5ee8306cb42f2d2df37e47c7f

Diff:

Revision 3 (+2204 -472)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

david
Review request changed

Change Summary:

Review Bot

Commits:

Summary ID
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still significant testing (manual and automatic) and documentation work to do on this, hence the WIP.
e31e376b3d67b0c5ee8306cb42f2d2df37e47c7f
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still significant testing (manual and automatic) and documentation work to do on this, hence the WIP.
86aeec0ffda74cbad866091290f4e730f50c3c90

Diff:

Revision 4 (+2300 -472)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

david
david
david
chipx86
  1. This is looking great. A few small things.

  2. rbtools/clients/__init__.py (Diff revision 7)
     
     
    Show all issues

    Probably should be , optional.

  3. rbtools/clients/clearcase.py (Diff revision 7)
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Show all issues

    The common part was split out, but these are overriding instead of appending to it.

  4. rbtools/clients/clearcase.py (Diff revision 7)
     
     
     
     
    Show all issues

    No blank line here.

  5. rbtools/clients/clearcase.py (Diff revision 7)
     
     
    Show all issues

    Typo: "becaue" -> "because"

  6. rbtools/clients/clearcase.py (Diff revision 7)
     
     
     
     
     
     
     
     
    Show all issues

    To ensure doc building works right, the format: should be format::. This will turn this into a code block.

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

    I have no idea if it's faster or not, but we can probably just have this be:

    if '%s/' % tag in path:
        break
    
  8. rbtools/clients/clearcase.py (Diff revision 7)
     
     
     
     
     
     
     
     
     
     
     

    Purely a suggestion, and not important for this change: Might be nice to have a _run_cleartool() command or something that takes the vobs or other things we need and builds them in a platform-dependent way in one place, so we can consolidate this sort of logic.

    The environment variable constants we define elsewhere could maybe be done on a class level.

  9. rbtools/clients/tests/test_clearcase.py (Diff revision 7)
     
     
    Show all issues

    Is "base clearcase" correct? Drawing a blank on the term. Is this just IBM ClearCase?

    1. Yeah, it's correct. The distinction here is base clearcase vs. UCM

  10. rbtools/clients/tests/test_clearcase.py (Diff revision 7)
     
     
    Show all issues

    Can we update these to use the formal capitalization of these names?

  11. rbtools/commands/diff.py (Diff revision 7)
     
     
     
    Show all issues

    Small nit: Alphabetical order?

  12. 
      
david
Review request changed

Change Summary:

  • Add in documentation for various posting modes.
  • Fix for when /main/1 has been rmvered.
  • Fix for finding the correct predecessor version in a UCM activity when revisions have been rmvered.
  • Fix up various comments and other minor things.

Summary:

-[WIP] Add support for VersionVault
+Add support for VersionVault

Description:

   

We will soon be adding a new SCMTool implementation to Power Pack to connect to

    HCL VersionVault and IBM ClearCase, supplanting the old community-driven
    ClearCase support. This change adds RBTools-side support for this.

   
   

This is based on code delivered to us in partnership with HCL, but has had

    significant changes. The largest change is that instead of having a completely
    separate SCMClient implementation in RBTools, this is built into the same
    ClearCase client. Most of the code paths are the same between the two types of
    backends, and the major difference is that the diff output for VersionVault
    includes additional information in the headers (the VOB OID for each changed
    element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order
    to do better post-processing on the diff display).

-  
-  

There's still significant testing (manual and automatic) and documentation work

-   to do on this, hence the WIP.

Testing Done:

  +
  • Posted changes from the current checkout (rbt post with no args) including
    new, modified, deleted, and binary files.
  +
  • Posted changes that spanned multiple VOBs.
  +
  • Posted a change that spanned multiple VOBs, including one that was not
    configured as part of the server-side repository. Saw expected
    warning.
  +
  • Posted changes for UCM activities for both a single and multiple
    revisions.
  +
  +

More testing to come.

Commits:

Summary ID
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still significant testing (manual and automatic) and documentation work to do on this, hence the WIP.
7e306ed82845f0d5b69d792163c4c3abd9d9aa11
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). Testing Done: - Posted changes from the current checkout (rbt post with no args) including new, modified, deleted, and binary files. - Posted changes that spanned multiple VOBs. - Posted a change that spanned multiple VOBs, including one that was not configured as part of the server-side repository. Saw expected warning. - Posted changes for UCM activities for both a single and multiple revisions.
bde4a7bc0ef4d2ecda01082b8c934e2a573cf5b6

Diff:

Revision 8 (+2776 -600)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

david
david
Review request changed

Change Summary:

  • Switch to DiffX
  • Add support for renamed and deleted files
  • Lots of bugfixing and cleanup

Description:

   

We will soon be adding a new SCMTool implementation to Power Pack to connect to

    HCL VersionVault and IBM ClearCase, supplanting the old community-driven
    ClearCase support. This change adds RBTools-side support for this.

   
   

This is based on code delivered to us in partnership with HCL, but has had

    significant changes. The largest change is that instead of having a completely
    separate SCMClient implementation in RBTools, this is built into the same
    ClearCase client. Most of the code paths are the same between the two types of
    backends, and the major difference is that the diff output for VersionVault
    includes additional information in the headers (the VOB OID for each changed
    element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order
    to do better post-processing on the diff display).

  +
  +

There's still more to do for unit testing but functionality should be

  + relatively complete at this point.

Testing Done:

~  
  • Posted changes from the current checkout (rbt post with no args) including
    new, modified, deleted, and binary files.
  ~
  • Posted changes from the current checkout (rbt post with no args) including
    new, modified, deleted, renamed, and binary files.
   
  • Posted changes that spanned multiple VOBs.
   
  • Posted a change that spanned multiple VOBs, including one that was not
    configured as part of the server-side repository. Saw expected
    warning.
   
  • Posted changes for UCM activities for both a single and multiple
    revisions.
~  
  ~
  • Ran unit tests.
-  

More testing to come.

Commits:

Summary ID
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). Testing Done: - Posted changes from the current checkout (rbt post with no args) including new, modified, deleted, and binary files. - Posted changes that spanned multiple VOBs. - Posted a change that spanned multiple VOBs, including one that was not configured as part of the server-side repository. Saw expected warning. - Posted changes for UCM activities for both a single and multiple revisions.
a64891d4216d0679c58dd1004f88618d5d48d295
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still more to do for unit testing but functionality should be relatively complete at this point. Testing Done: - Posted changes from the current checkout (rbt post with no args) including new, modified, deleted, renamed, and binary files. - Posted changes that spanned multiple VOBs. - Posted a change that spanned multiple VOBs, including one that was not configured as part of the server-side repository. Saw expected warning. - Posted changes for UCM activities for both a single and multiple revisions. - Ran unit tests.
b9e115117fdd860fa9ce143bcfe611eab5e7643e

Diff:

Revision 10 (+3694 -712)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

david
chipx86
  1. 
      
  2. docs/rbtools/rbt/commands/post.rst (Diff revision 11)
     
     
     
     
     
     
    Show all issues

    Given how old this is, let's nuke it and instead put 3.0, and mention the new support.

  3. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
     
     
     
    Show all issues

    Can you add "Version Added"?

  4. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
    Show all issues

    I don't know what's really correct, but historically we've put __init__ before @properties. We should probably err on the side of consistency.

  5. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
    Show all issues

    Minor thing, but should these have quotes around the examples?

  6. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
    Show all issues

    Maybe double backticks around teh <...> bits?

  7. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
    Show all issues

    This isn't true anymore, right? Given the docs in the function.

  8. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
    Show all issues

    Is there supposed to be a trailing comma on -predecessor?

  9. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Show all issues

    Can we maek this a standard private function? I feel like this doesn't really need to be inline like this.

  10. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
    Show all issues

    These could be combined.

  11. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
     
    Show all issues

    Given that we never really need i, this can probably just be a standard for f in files.

  12. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
     
    Show all issues

    Same as above.

  13. rbtools/clients/clearcase.py (Diff revision 11)
     
     
     
     
     
    Show all issues

    Same as above.

  14. rbtools/clients/clearcase.py (Diff revision 11)
     
     
    Show all issues

    This is repeated a lot. How about building the base command line outside the loop, then just do cmdline + [old_file] (etc)?

  15. rbtools/clients/tests/test_clearcase.py (Diff revision 11)
     
     
     
     
    Show all issues

    Just to check, is the extra space on the 3rd line here intentional? It shows up on the other examples below as well.

    1. This is all copied out of actual cleartool output, so I'd rather keep it even though it's weird.

  16. 
      
david
Review request changed

Commits:

Summary ID
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still more to do for unit testing but functionality should be relatively complete at this point. Testing Done: - Posted changes from the current checkout (rbt post with no args) including new, modified, deleted, renamed, and binary files. - Posted changes that spanned multiple VOBs. - Posted a change that spanned multiple VOBs, including one that was not configured as part of the server-side repository. Saw expected warning. - Posted changes for UCM activities for both a single and multiple revisions. - Ran unit tests.
f81650abb73d868ea522905bd3aaae38493eebdf
Add support for VersionVault
We will soon be adding a new SCMTool implementation to Power Pack to connect to HCL VersionVault and IBM ClearCase, supplanting the old community-driven ClearCase support. This change adds RBTools-side support for this. This is based on code delivered to us in partnership with HCL, but has had significant changes. The largest change is that instead of having a completely separate SCMClient implementation in RBTools, this is built into the same ClearCase client. Most of the code paths are the same between the two types of backends, and the major difference is that the diff output for VersionVault includes additional information in the headers (the VOB OID for each changed element, and a JSON-encoded blob to drop into the FileDiff's extra_data in order to do better post-processing on the diff display). There's still more to do for unit testing but functionality should be relatively complete at this point. Testing Done: - Posted changes from the current checkout (rbt post with no args) including new, modified, deleted, renamed, and binary files. - Posted changes that spanned multiple VOBs. - Posted a change that spanned multiple VOBs, including one that was not configured as part of the server-side repository. Saw expected warning. - Posted changes for UCM activities for both a single and multiple revisions. - Ran unit tests.
2471c774ee43c7e8aa3ecad97bb8f388b9cc3a5a

Diff:

Revision 12 (+3740 -720)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 failed.
JSHint passed.

flake8

david
chipx86
  1. 
      
  2. docs/rbtools/rbt/commands/post.rst (Diff revisions 11 - 13)
     
     
     
    Show all issues

    Definitions generally go at the bottom of the section (the rest of our docs do this).

  3. rbtools/clients/clearcase.py (Diff revisions 11 - 13)
     
     
    Show all issues

    The "3.0" has to be on the next line for section parsing to consider this correctly.

  4. rbtools/clients/clearcase.py (Diff revisions 11 - 13)
     
     
    Show all issues

    "a was removed" -> "was removed"

  5. rbtools/clients/clearcase.py (Diff revisions 11 - 13)
     
     
    Show all issues

    "Return ..." better describes what this is doing.

  6. 
      
david
chipx86
  1. Ship It!
  2. 
      
david
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to master (5f733db)
Loading...