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

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

            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: