Difference: LHCbRichMirrorAlignGitInfo (31 vs. 32)

Revision 322018-02-12 - ParasNaik

Line: 1 to 1
 
META TOPICPARENT name="LHCbRichMirrorAlign"
Line: 24 to 24
  It is time to git! Please read everything and please follow the workflow Anatoly describes. If you have any questions email the alignment-development mailing list. If we cannot answer your question, email Jordi, and if all else fails then Marco Clemencic / lhcb-core-soft@cernNOSPAMPLEASE.ch
Changed:
<
<
The basic idea behind git is that "branches" are used to develop new features of the code, each branch forks from the master branch (the "default" branch) of a git repository, and each new branch is isolated from the other branches, until one chooses to merge them. Typically we use these other branches for development, and then merge them back to the master branch when the new feature is tested and ready. At LHCb we have to ask for a merge request in CERN's GitLab to merge one of our branches into the master branch of a Project. Then the Project manager can decide whether to allow the merge to occur.
>
>
The basic idea behind git is that "branches" are used to develop new features of the code, typically each branch forks from the main master branch (the "default" branch) of a git repository, and each new branch is isolated from the other branches, until one chooses to merge them. Typically we use these other branches for development, and then merge them back to the master branch when the new feature is tested and ready. At LHCb we have to ask for a merge request in CERN's GitLab to merge one of our branches into (typically) the master branch of a Project. Then the Project manager can decide whether to allow the merge to occur.

NOTA BENE: However, Panoptes is currently using two main branches. One is called 2018-patches and applies only to 2018 operations, the other is called master and will be used in the upgrade. This significantly changes our workflow:

  • Always lb-checkout out code from 2018-patches and commit any changes to a new branch
  • As usual, set up a merge request when ready to merge the new branch into the 2018-patches branch.
  • NEW Cherry-pick commits from 2018-patches into a second new branch.
  • Set up a merge request when ready to merge the second new branch into the master branch.
This seems complicated but it's the only way we can ensure that our changes go into both branches, as the master branch will soon have much code stripped away and changed in favor of the upgrade era code.
 

Standard documentation and other git stuff

Line: 51 to 58
 
  • However, packages don't have version tags anymore. From now on, a Panoptes project tag affects all its packages. What used to be "version v2r26 of Rich/RichOnlineMonitors" is now the "Rich/RichOnlineMonitors that comes with Panoptes v5r6."
  • The tag collector becomes obsolete from the point of view of Panoptes.
Changed:
<
<
  • Since we still need to release Panoptes versions, all packages should at least compile when they are added to the master branch of the git repository.
>
>
  • Since we still need to release Panoptes versions, all packages should at least compile when they are added to the 2018-patches / master branch of the git repository.
  For this reason, it is important to have meaningful development branches for stuff that is not yet stable, which will be merged once the new features are fully implemented and tested.
Line: 60 to 67
 
  • Implement the features in a branch.
  • Test them.
  • Push the branch to an upstream repository (e.g. a fork of the project in gitlab).
Changed:
<
<
  • Submit a merge request, so the new features are included in the master branch.
>
>
  • Submit a merge request, so the new features are included in the 2018-patches / master branch.
  Please get used to the git workflow ASAP.
Line: 122 to 129
 The output of this last command will give you information like this:
 * [new branch]      master     -> Panoptes/master <br>
Added:
>
>
* [new branch] 2018-patches -> Panoptes/2018-patches
  * [new tag] v1r0 -> Panoptes/v1r0
[...]
* [new tag] v7r1 -> Panoptes/v7r1
Line: 129 to 137
 

You will see that there are several references that you can use.

Changed:
<
<
Some of them are branches (in this example, only master) and some of them are tags.
>
>
Some of them are branches (in this example, 2018-patches and master) and some of them are tags.
 You will refer to them as Panoptes/[reference], as in the last column of the previous output.
Changed:
<
<
Let's say you want to develop on top of the Rich/RichMirrorAlignmentOnline package that you can find on the master branch.
>
>
Let's say you want to develop on top of the Rich/RichMirrorAlignmentOnline package that you can find on the 2018-patches branch.
 To checkout a package (e.g before you start work on a new package for the first time):
  • git fetch --all (ALWAYS do this before any lb-checkout, it updates the local information about branches with the current information from the git repository.)
Changed:
<
<
  • git lb-checkout Panoptes/master Rich/RichMirrorAlignmentOnline (or perhaps a different package that you might be working on (e.g. Rich/RichMirrAlign))
>
>
  • git lb-checkout Panoptes/2018-patches Rich/RichMirrorAlignmentOnline (or perhaps a different package that you might be working on (e.g. Rich/RichMirrAlign))
 
    • This is the git equivalent of checking out the package from the SVN head.

Now you may edit the code and add new features. You would obviously not necessarily edit the same files as shown in this example, but whatever pieces of code you actually wanted to edit.

Line: 190 to 198
  Here, your equivalent of username-title-YYYYMMDD is the name of your development branch, and you will be able to see it in gitlab.
Changed:
<
<
If you then would like the commits in username-title-YYYYMMDD to be merged into master, you must perform a Gitlab merge request.
>
>
If you then would like the commits in username-title-YYYYMMDD to be merged into 2018-patches, you must perform a Gitlab merge request.
 You may submit a merge request for asolomin-MirrAlign-20170123 from the Panoptes gitlab page You can also use the hyperlink provided when you commit, though if it's a sensitive change you may want to look at your commit in gitlab first. NOTE: Your pushed branch (that contains your commit) MUST COMPILE locally to get accepted (though it may not compile against the nightlies, consult Chris and Jordi if you find this problem).
Line: 208 to 216
  This shouldn't happen in our workflow, but just so you know about it... If changes were made to your branch [e.g. in GitLab] by someone else, and then you want to keep working on the branch:
Changed:
<
<
  • git fetch --all # (you must do this in order to get access to remote changes in Panoptes/master or any other branch)
>
>
  • git fetch --all # (you must do this in order to get access to remote changes in Panoptes/2018-patches or any other branch)
 
  • git lb-checkout Panoptes/asolomin-MirrAlign-20170123 Rich/RichMirrorAlignmentOnline
Changed:
<
<
After the merge requests are applied and only after, when you are ready to start work again you will want to update your local packages from the master, in case there were any changes in the master in the meantime:
>
>
After the merge requests are applied and only after, when you are ready to start work again you will want to update your local packages from the 2018-patches, in case there were any changes in the 2018-patches in the meantime:
 
  • cd $User_release_area/PanoptesDev_v7r3
Changed:
<
<
  • git fetch --all # (Remember, you must do this in order to get access to remote changes in Panoptes/master or any other branch)
  • git lb-checkout Panoptes/master Rich/RichMirrorAlignmentOnline (and the same for ALL other packages you checked out from master, unless you are still working on a branch of a different package)
>
>
  • git fetch --all # (Remember, you must do this in order to get access to remote changes in Panoptes/2018-patches or any other branch)
  • git lb-checkout Panoptes/2018-patches Rich/RichMirrorAlignmentOnline (and the same for ALL other packages you checked out from 2018-patches, unless you are still working on a branch of a different package)
  *If someone else has lb-pushed a new feature branch called that-branch to Panoptes, you can bring that branch instead to your local copy with
  • git fetch --all
  • git lb-checkout Panoptes/that-branch Rich/RichMirrorAlignmentOnline
Changed:
<
<
In this manner you can change your local copy of the repository for a package very simply, from that which exists in one branch to another. However you should be typically starting fresh from the Panoptes/master branch before adding new features.
>
>
In this manner you can change your local copy of the repository for a package very simply, from that which exists in one branch to another. However you should be typically starting fresh from the Panoptes/2018-patches branch before adding new features.
  If you want to see what's been happening with respect to the local code interacting with the git repository, at any stage, just go here:
Line: 273 to 281
  If you no longer want the merge request to be accepted (e.g. it was done by mistake) then close the merge request. If the associated branch is no longer in use you may delete it from the Hlt gitlab page.
Added:
>
>

Cherry-picking commits from 2018-patches into master

In the new workflow, we always work with 2018-patches as our starting branch, and we will use 2018-patches as the default branch at the pit as well. However, since for the time being we also want the upgrade code to have all of the changes we made, we are required to manually cherry-pick commits we make to 2018-patches to a new branch, and then merge that new branch into master.

There are several ways to do this, which will not be discussed here. However this is something that you have to do, so if you can't figure it out please contact all the mirror alignment experts for advice.

 

Notes from Paras about our global workflow

Typically before we submit a merge request, we want to "svn update" or whatever the equivalent of getting changes that others made in the repository over to our branch, and then "rebased". However, as of June 2017 I am still not exactly sure how to do it correctly.

Changed:
<
<
Fortunately with GitLab, we can leave (simple) rebasing to the Project managers. Just prepare your change then commit. You can start your merge request in gitlab right away, but if you don't want it to be actually merged please put "WIP: " in front of the title of the merge request. Then you can commit more to that branch if you want. But as soon as it is ready please remove "WIP: " and ask Jordi or Chris to merge the branch. Then after the branch is merged update locally to what is in master:
>
>
Fortunately with GitLab, we can leave (simple) rebasing to the Project managers. Just prepare your change then commit. You can start your merge request in gitlab right away, but if you don't want it to be actually merged please put "WIP: " in front of the title of the merge request. Then you can commit more to that branch if you want. But as soon as it is ready please remove "WIP: " and ask Jordi or Chris to merge the branch. Then after the branch is merged update locally to what is in 2018-patches:
 
Changed:
<
<
  • git fetch --all # (you must do this in order to get access to remote changes in Panoptes/master or any other branch)
  • git lb-checkout Panoptes/master Rich/RichMirrAlign (or instead of Rich/RichMirrAlign, whichever package you are going to work on)
>
>
  • git fetch --all # (you must do this in order to get access to remote changes in Panoptes/2018-patches or any other branch)
  • git lb-checkout Panoptes/2018-patches Rich/RichMirrAlign (or instead of Rich/RichMirrAlign, whichever package you are going to work on)
 

Further details on git commands (thanks to Jordi)

Changed:
<
<
1. You should not associate the master branch with the SVN trunk. In SVN, tagged packages were expected to work, and committers could add unstable stuff to the trunk. With the new workflow that we believe is reasonable for Panoptes, the master branch is expected to always be stable, as opposed to the SVN trunk. Unstable contributions to git should take place in branches. So, to summarize, in svn, new contributions go from an unstable trunk to stable branches and from there to release. In git, new contributions go from unstable branches to stable master and from there to release.
>
>
1. You should not associate the 2018-patches / master branch with the SVN trunk. In SVN, tagged packages were expected to work, and committers could add unstable stuff to the trunk. With the new workflow that we believe is reasonable for Panoptes, the 2018-patches / master branch is expected to always be stable, as opposed to the SVN trunk. Unstable contributions to git should take place in branches. So, to summarize, in svn, new contributions go from an unstable trunk to stable branches and from there to release. In git, new contributions go from unstable branches to stable 2018-patches / master and from there to release.
  2. Basically the only place a package v-tag should show up is within the CMakeLists and cmt/requirements of each package. Otherwise we do not tag packages officially (they can be tagged unofficially in commits and in the release notes). However, the Panoptes project should be the only thing that is officially v-tagged.
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback