Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/Git"

< E4
(Submitting for a build)
(Submitting for a build)
Line 27: Line 27:
 
''Note:'' We have a policy that all commits have the associated bug number.  Usually our format is:
 
''Note:'' We have a policy that all commits have the associated bug number.  Usually our format is:
 
  Bug <number> - <bug title>
 
  Bug <number> - <bug title>
and then any specific comments after the title or on the next line.  It's important that we only list 1 bug # per line, and at the beginning.  A line with "bug #" or "Bug #" without the title is also acceptable.
+
and then any specific comments after the title or on the next line.  It's important that we only list 1 bug # per line, and at the beginning of the line.  A line with "bug #" or "Bug #" without the title is also acceptable.
  
 
When ready to submit deeplinking for the build, you have to submit 2 repos, org.eclipse.e4.deeplink and org.eclipse.e4.utils.  For each repo:
 
When ready to submit deeplinking for the build, you have to submit 2 repos, org.eclipse.e4.deeplink and org.eclipse.e4.utils.  For each repo:

Revision as of 10:52, 22 October 2010

Git in e4

We have a place in e4 for git repositories.

Current Repos

A repo then follows our standard subdir convention:

  • bundles
  • features
  • examples
  • tests

We build our git repos still using map files, checked into CVS in the /cvsroot/eclipse e4/releng module.

Submitting for a build

We have 2 scripts used for submitting for the build. One to update the map files, and one to generate the submission report for our mailing list e4-dev@eclipse.org

git-map.sh is used to update the map files.

git-submission.sh is used to generate a build submission report.

Note: We have a policy that all commits have the associated bug number. Usually our format is:

Bug <number> - <bug title>

and then any specific comments after the title or on the next line. It's important that we only list 1 bug # per line, and at the beginning of the line. A line with "bug #" or "Bug #" without the title is also acceptable.

When ready to submit deeplinking for the build, you have to submit 2 repos, org.eclipse.e4.deeplink and org.eclipse.e4.utils. For each repo:

  1. cd into the repo (make sure it's up to date, you're on the master branch, etc)
  2. tag the repo: git tag v20101022-1030 # we use vDATE-TIME as our tag
  3. make sure you push the tag back to the public repo
  4. run the script (see example below)
  5. You'll have to execute the script for each subdiretory: bundles, examples, features, tests.
  6. Repeat the steps for the second repo.
  7. Then refresh your workspace and commit.

git-map.sh example:

$ /bin/bash git-map.sh v20101022-1030 /opt/pwebster/workspaces/e4/releng/org.eclipse.e4.deeplink.releng/maps/deeplink.map  bundles
  

Then when done you can generate your build submission report for the e4-dev list:

$ /bin/bash git-submission.sh >report.txt

Back to the top