Transition to GitHub

Development
1

Here is a preview of what will be the final GitHub repository hosting Slicer sources: https://github.com/jcfr/Slicer-Git
Update: Preview repository has been removed. Sources are now available at https://github.com/Slicer/Slicer

Next steps:

Waiting we officially transition, please consider reviewing the history and reporting here if authorship or committer is incorrect.

For future reference, scripts and instructions are archived at https://github.com/jcfr/Slicer-github-transition-scripts

2 Likes
2

This will help us in so many ways, thank you for working on this!

Are you going to add stubs for issues in the bugtracker? (just the subject line, a link to the issue tracker, maybe first N lines of the issue description)

A few tweaks (none of them very important):
-Maybe we could fix links to the SVN repository (e.g., the commit comment contains “git-svn-id: http://svn.slicer.org/Slicer4/trunk@28773” but this URL is not valid)

  • Maybe add a url to the corresponding commit in the old repository (so that we can easily find a commit based on the old hash)
3

That will be great!

not complelty related this, but I was wandering if it would be possible to fix the co-authorship for the following commits:

  1. markups
    https://github.com/jcfr/Slicer-Git/commit/b4098a06bdcbb4ccf33d44c0afc1e201d3590682
    https://github.com/Slicer/Slicer/commit/23d076495be731efe23cfa1ffdd8a920524a489e

  2. 3d views linking
    https://github.com/jcfr/Slicer-Git/commit/5c04e5c286760eeccf5f02a1eaff8efc77102dd1
    https://github.com/Slicer/Slicer/commit/3bf8417efd7b949610a8a3765d058e8d3997135f

Andras can confirm my co-authorship for the two commits which I think it was lost in the review/merge process. If it is not possible to add the co-authorship anymore, no problem.
Thanks!

1 Like
4

yes

Maybe we could fix links to the SVN repository (e.g., the commit comment contains “git-svn-id: http://svn.slicer.org/Slicer4/trunk@28773” but this URL is not valid)

Good point. Instead I was thinking to add an other line of the form:

svn-url: http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24838

Of course, I will do.

Note that I will resume work on the transitioning to GitHub when back from traveling after March 1st.

1 Like
5

Sounds good. Thanks for all your hard work on this.

6

Any progress on moving to git. It is a bit annoying that contributions to svn to not retain attributions very well.

7

I really hope that @jcfr completes this within days and not weeks.

We save original author in commit comments and use it to look up author when converting the repository to git.

8

Thanks @lassoan I appreciate your support.

Sometimes attribution is the only compensation contributors get!

2 Likes
9

Yess, I re-ran all scripts yesterday and will plan on wrapping up next week. (Note: I am out of the office today and Monday)

1 Like
10

Has there been any progress on this transition?

11

Working on this today. Stay tuned :rocket:

Waiting this is complete, do not commit on either SVN or GitHub

cc: @lassoan @pieper @Sam_Horvath @fedorov @cpinter

3 Likes
12

The current repository has been renamed to https://github.com/Slicer/SlicerGitSVNArchive and a new repository called Slicer has been created.

  • The new Slicer/Slicer is NOT yet ready for usage, the history will likely be updated tonight.
  • Preview build will be disabled tonight and re-enabled tomorrow.

Thanks for your patience

3 Likes
13

Can we get an update on this process?

14

Stub issues mapping with the mantis ones are being created.

1 Like
15

Waiting all stub issues are created do NOT follow the Slicer repository on GitHub, it will spam your inbox.

Cc: @cpinter @lassoan @pieper

1 Like
16

The new repo will be ready to accept contribution (Pull requests, new issue, comments, …) tomorrow

Nightly build will be re-enabled tonight.

Thanks for your patience

In the mean time, what should you do ?

Details:

Next steps:

8 Likes
17

Thank you so much @jcfr for working on the migration! :pray: This was very important and delicate, so also thanks for doing it with such care :slight_smile:

2 Likes
18

This is awesome! :champagne:

Thank you @jcfr for performing this migration with so much attention to all details. Preserving all the various links, history, contributions, etc. will be very valuable.

Can we start submitting pull requests (and rebase&merge them)?

19

@jcfr Awesome! Waiting for the green light ot make PR’s.

Hans

20

Few more things to set up:

  1. We should make master branch protected
  • “Allow force pushes” and “Allow deletions” unchecked: This make things safer and simpler (at the cost of not being able to cover up potential missteps). It also allows us to use commit count as a monotonously increasing counter for easier revision tracking (instead of SVN revision). It is a minor inconvenience that merge count does not appear in github GUI, but we can determine it quite easily at project build time.
  • Require pull request reviews before merging: checked (we should try this at least and disable if we find it too annoying or it slows things down too much)
  • Require status checks to pass before merging: unchecked (for now, until we are confident that checks work very reliably)
  • Require signed commits: unchecked (I have never used this, but probably not necessary)
  • Require linear history: checked (non-linear history is just too complicated)
  • Include administrators: unchecked (there is a warning displayed anyway if you exercise this right, that should be enough)
  • Restrict who can push to matching branches: checked (have a CoreDevelopers or similar sub category who are allowed to merge changes)

  1. Disable “Create a merge commit” option (only allow “Squash and merge” and “Rebase and merge”). Merge commits make reviewing change history a very complicated task.

  2. Create Developers group and add people who we want to be able to assign issues to.

1 Like