Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10
    • Component/s: infrastructure
    • Labels:
      None

      Description

      As an initial step, the various repositories can be combined in a way which preserve their current relative file layout.

        Issue Links

          Activity

          darcy Joe Darcy created issue -
          darcy Joe Darcy made changes -
          Field Original Value New Value
          Fix Version/s 10 [ 16302 ]
          darcy Joe Darcy made changes -
          Status New [ 10000 ] Open [ 1 ]
          darcy Joe Darcy made changes -
          Link This issue blocks JDK-8165185 [ JDK-8165185 ]
          darcy Joe Darcy made changes -
          Link This issue relates to JDK-8165187 [ JDK-8165187 ]
          erikj Erik Joelsson made changes -
          Assignee Erik Helin [ ehelin ] Erik Joelsson [ erikj ]
          Hide
          erikj Erik Joelsson added a comment - - edited
          I have been continuing this work for a while. We had a report that crucible had a hard time with the unified repo from the prototype. This was likely caused by the 8 separate "root" change sets that don't share a common ancestor. In my new strategy, instead of just pulling in the old repository contents as is, and then merging at each tag, I use the convert extension to convert changes in and splice in the new promoted tag changes as new parents. This results in a truly combined history.

          To give a little more detail (but still simplified). Changes are imported one tag at a time. When importing tag X, for each src repository, find the children of X-1 in the src repo. In the new repository, replace the parent of those changes with the newly created merge change with tag X-1 in the new repository. When all repos have been imported for tag X, merge them together to create one single point and tag that with X.

          The result of this is that for each tag, the unified repo is identical content wise with the old forest. For any change in between tags, files from the same src repo are consistent and the the files from other repos will be at the state of the last tag.

          I have also activated a feature in the convert extension that saves the original hash in the extras part of each changeset in the unified repo.
          Show
          erikj Erik Joelsson added a comment - - edited I have been continuing this work for a while. We had a report that crucible had a hard time with the unified repo from the prototype. This was likely caused by the 8 separate "root" change sets that don't share a common ancestor. In my new strategy, instead of just pulling in the old repository contents as is, and then merging at each tag, I use the convert extension to convert changes in and splice in the new promoted tag changes as new parents. This results in a truly combined history. To give a little more detail (but still simplified). Changes are imported one tag at a time. When importing tag X, for each src repository, find the children of X-1 in the src repo. In the new repository, replace the parent of those changes with the newly created merge change with tag X-1 in the new repository. When all repos have been imported for tag X, merge them together to create one single point and tag that with X. The result of this is that for each tag, the unified repo is identical content wise with the old forest. For any change in between tags, files from the same src repo are consistent and the the files from other repos will be at the state of the last tag. I have also activated a feature in the convert extension that saves the original hash in the extras part of each changeset in the unified repo.
          Hide
          erikj Erik Joelsson added a comment -
          I believe I have the bare repository conversion down now, basically as described in the comment above. There is one extra complication introduced when JDK 9 started merging into JDK 10 as we then no longer have a linear progression of tag changesets (where each tag change is parent of the next). To handle that, and still make the JDK 9 tags valid, I handled the JDK 9 tags after jdk-10+01 by just creating a new merge point and tagging that.
          Show
          erikj Erik Joelsson added a comment - I believe I have the bare repository conversion down now, basically as described in the comment above. There is one extra complication introduced when JDK 9 started merging into JDK 10 as we then no longer have a linear progression of tag changesets (where each tag change is parent of the next). To handle that, and still make the JDK 9 tags valid, I handled the JDK 9 tags after jdk-10+01 by just creating a new merge point and tagging that.
          erikj Erik Joelsson made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          erikj Erik Joelsson made changes -
          Status In Progress [ 3 ] New [ 10000 ]
          Understanding Fix Understood [ 10001 ]
          erikj Erik Joelsson made changes -
          Status New [ 10000 ] Open [ 1 ]
          erikj Erik Joelsson made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          erikj Erik Joelsson made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Understanding Fix Understood [ 10001 ]
          Resolution Fixed [ 1 ]
          erikj Erik Joelsson made changes -
          Summary Combine repositories with same relative file layout Preparation: Combine repositories with same relative file layout

            People

            • Assignee:
              erikj Erik Joelsson
              Reporter:
              darcy Joe Darcy
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: