<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Folks,</p>
    <p id="firstHeading" class="firstHeading" lang="en">I've attempted
      to provide some guidance on how to use your old sim-recon branches
      and tags now that we have split up sim-recon. You can find it <a
        moz-do-not-send="true"
href="https://halldweb.jlab.org/wiki/index.php/Converting_sim-recon_tags_and_branches_to_the_split_repositories">here</a>
      and below. Note that is also linked from the <span dir="auto"><a
          moz-do-not-send="true"
          href="https://halldweb.jlab.org/wiki/index.php/Splitting_sim-recon">Splitting
          sim-recon wiki page</a>.</span></p>
    <p class="firstHeading" lang="en"><span dir="auto">  -- Mark</span></p>
    <p class="firstHeading" lang="en"><span dir="auto">___________________</span></p>
    <p class="firstHeading" lang="en"><br>
      <span dir="auto">
      </span></p>
    <div id="globalWrapper">
      <div id="column-content">
        <div id="content" class="mw-body" role="main">
          <h1 id="firstHeading" class="firstHeading" lang="en"><span
              dir="auto">Converting sim-recon tags and branches to the
              split repositories</span></h1>
          <div id="bodyContent" class="mw-body-content">
            <div id="siteSub">From GlueXWiki</div>
            <div id="mw-content-text" dir="ltr" class="mw-content-ltr"
              lang="en">
              <p>First recall that the new halld_recon and halld_sim
                repositories are complete clones of the old sim-recon
                repository. That means they both contain all of the
                history of sim-recon as well as all of its tags and
                branches. The fact that not all of the old directories
                appear is that they have been deleted in a git-like
                manner. Those directories are still present in the
                history of each of the new repositories. The src/SBMS
                directory is the only directory contained in both. It
                had been modified in a new-repository-specific way for
                each new repository.
              </p>
              <h2><span class="mw-headline" id="Branches">Branches</span></h2>
              <p>When you checkout your old sim-recon branch from a
                halld_recon or halld_sim repository, you will get the
                entire tree in its old sim-recon form. In particular you
                will get all of the code for both the sim stuff and tne
                recon stuff, and an SBMS directory that is meant to
                build both. That is after all, the last thing you pushed
                to the sim-recon repository. In the majority of cases,
                this is not a problem. You can do the sim-recon-style
                build even though the "origin" repository is halld_recon
                or halld_sim, test the resulting binaries, push your
                changes to halld_recon or halld_sim as appropriate, and
                submit your pull request as before. The subsequent merge
                will use the new repository-appropriate SBMS directory,
                delete the directories that are now in the "other"
                repository and update the master with your changes.
              </p>
              <p>Another scenario is that you want to maintain your
                changes on your branch, but want to transform the branch
                to have the new repository-specific build procedure and
                directories. In that case, you can merge the master onto
                your branch. That merge will delete the directories now
                in the "other" repository and update your SBMS directory
                to do the new right thing.
              </p>
              <h3><span class="mw-headline" id="Conflicts">Conflicts</span></h3>
              <p>The guidance above is fine unless there are conflicts.
                There are two types of conflicts:
              </p>
              <ol>
                <li> The standard conflict: you have made changes on
                  your branch and the master branch has different
                  changes to the same file in the same section of code.</li>
                <li> The split-induced conflict: the split of sim-recon
                  itself caused the conflict to occur. There are two
                  sub-types.
                  <ol>
                    <li> Your branch has changes to both recon
                      directories and sim directories.</li>
                    <li> You branch has changes to the SBMS directory.</li>
                  </ol>
                </li>
              </ol>
              <p>Case (1) is nothing new. You have to resolve it in the
                usual way.
              </p>
              <p>Case (2.1) will occur when you branch has changes to
                both sim directories and recon directories. For example,
                you have made changes to a sim directory on the old
                branch and have checked out from the halld_recon
                repository. In this case the merge with the master would
                normally delete all sim files, but git notices you have
                changed some of these files and flags that situation as
                a conflict. You can resolve the conflict by performing a
                <code>git rm</code> on all of the flagged sim files and
                then perform the commit. Recall that those changes are
                present on the same branch in the halld_sim repository.
                And vice versa for recon changes checked out from
                halld_sim.
              </p>
              <p>Case (2.2) will only be encountered by experts and they
                must rely on said expertise to resolve the situation.
              </p>
              <h2><span class="mw-headline" id="Tags">Tags</span></h2>
              <p>Tags are tricker since merging to perform the update is
                not an option. To do a merge at all you have to create a
                branch from the tag, but if you merge in the master
                branch, that will bring in changes on the master and
                defeats the idea of a tag.
              </p>
              <p>Here it is easiest to build the tag as-is, i. e., with
                a sim-recon-style build and use it that way. In other
                words, don't try to convert it.
              </p>
              <p>There are ways to actually do the conversion, but if
                you need to do that see an expert.
              </p>
            </div>
            <div class="printfooter">
              Retrieved from "<a dir="ltr"
href="https://halldweb.jlab.org/wiki/index.php?title=Converting_sim-recon_tags_and_branches_to_the_split_repositories&oldid=88526">https://halldweb.jlab.org/wiki/index.php?title=Converting_sim-recon_tags_and_branches_to_the_split_repositories&oldid=88526</a>"</div>
          </div>
        </div>
      </div>
      <div id="footer" role="contentinfo">
        <ul id="f-list">
          <li id="lastmod"> This page was last modified on 31 July 2018,
            at 14:30.</li>
        </ul>
      </div>
    </div>
    <pre class="moz-signature" cols="72">
-- 
Mark Ito, <a class="moz-txt-link-abbreviated" href="mailto:marki@jlab.org">marki@jlab.org</a>, (757)269-5295
</pre>
  </body>
</html>