Deprecate SVN service: December 1,2022
A few years ago we moved pretty much all of our projects to Git and our other VCS offerings were either shutdown(CVS) or put into mothballs(SVN). The time has come to finally move SVN into the 'shutdown' category.
/cc @wbeaton /cc @npeifer1fn
Activity
added IT-prioritylow Infra Servers labels
assigned to @mward
/cc @afedorov3un
@npeifer1fn we need a plan where to migrate. My vote is for GitLab hosted by EF. Please provide your comments.
@afedorov3un I'm for Eclipse's GitLab instance, too. In my opinion, this should be the next step after the upcoming release has been reviewed successfully. Then we have a "clean cut".
I don't have a clue how the migration has to be done. Do I have to do it manually? Is there any guide I can follow?
Edited by Nicolas PeiferWell git does have some inbuilt SVN support[1] for doing the transfer so that's probably the safest option, although you may be able to find 'better' tools.
I think the general workflow should be:
- Project picks a Git service (This appears to be done, and this Gitlab instance was picked)
- Webmaster creates the project/repo on Gitlab
- The project team does the SVN-Git migration locally and makes sure they're happy
- The Project pushes the converted repo to Gitlab
- The project updates their local dev tools to use Gitlab
- Profit.
If that sounds ok to you, I can get step 2 underway.
@mward Awesome, thanks for your reply and pointing out the necessary/possible steps.
I agree, you can proceed with creating the project on this GitLab instance.
Ok, https://gitlab.eclipse.org/eclipse/subversive/subversive has been created.
Committers should receive access in an hour or so when the sync tooling runs.
Ok, I'm close to the finish line. But when pushing the new Git repository, I get errors like the following for multiple committers:
remote: Reviewing commit: 5eacd6823a3323abe3bf8d5751ce14b710cb013b remote: Authored by: Alexei Goncharov <a...v@p...n.org> remote: Eclipse user 'agoncharo'(committer) is not a committer on the project. remote: Eclipse user 'agoncharo'(committer) does not have a current Eclipse Contributor Agreement (ECA) on file. remote: If there are multiple commits, please ensure that each author has a ECA. remote: remote: Errors: remote: An Eclipse Contributor Agreement is required for Eclipse user 'agoncharo'(author). remote: An Eclipse Contributor Agreement is required for Eclipse user 'agoncharo'(committer). remote: Any warnings or errors noted above may indicate compliance issues with committer ECA requirements. More information may be found on https://www.eclipse.org/legal/ECA.phpHere is a report that was linked in the output: https://api.eclipse.org/git/eca/status/f07ee5f2076fdfd1107e2142a8b79598/ui
All authors in the Git log have the correct scheme "Name <email address>". I just censored the email address in the output above in order to protect the privacy of the author.
I don't know how to proceed. Any ideas?
Edited by Nicolas PeiferSorry for the delay in responding.
I think this is caused by the ECA checker not being able to correctly map these older committers, and I'm not sure what the best way is to 'fix' that. One option might be to create a git repo somewhere like github and have you push the converted repo there and then I could try to do an import of that, but I'm not sure if that will also hit the ECA check.
@webdev any suggestions here?
Pushing this code to a fork under @npeifer1fn GitLab account and then moving it might also work for now.
If it doesn't, we have the option of deploying a temporary exception in the ECA.rb script to stop blockiung commits from contributors without a current ECA on file with us.
We would need to redeploy an update to remove that exception. I would recommend that we try pushing to a fork first.
Edited by Christopher Guindon
@cguindon Nice, pushing to a fork under my user account and then transferring it to the Subversive project worked. Thanks
@mward The imported sources are now in the "Subversive Imported Sources" project at https://gitlab.eclipse.org/eclipse/subversive. In theory, the old and empty "subversive" sub-project can now be replaced by this project. Do you want/have to do this or can I just delete the old sub-project and rename the imported project to "subversive"?
I've removed the old empty subversive repo and replaced it(with rename) with the imported source. All I think that needs to happen now is to update any local copies to use the new URL for their remotes.
Once you've confirmed that everything is working we can continue to close the SVN service.
-
It was designed as a feature but we are changing that based on my latest proposal. We wanted to make it easy for folks to contribute so we decided at that time to only block contributions when they were pushed to an Eclipse Project repo:
I started a conversation 2 weeks ago proposing that we consider requiring ECA validation on all commits eclipsefdn/it/api/git-eca-rest-api#92
Edited by Christopher Guindon -
I think it's also worth mentioning that we trust our committers to not circumvent the ECA.
Edited by Christopher Guindon
-
@npeifer1fn please announce the source transition using the mailing list. It would also be great to understand what we are going to use as a change tracking system: do you think it could be https://gitlab.eclipse.org/eclipse/subversive/subversive/-/issues instead of Bugzilla?
After arguing with the tooling and Gitlab for a while I've managed to import all of the open SVN bugs here: https://gitlab.eclipse.org/eclipse/subversive/test-project2 .
@npeifer1fn can you take a look a the issues list for that project and let me know if it's ok(ie: has the data you generally expect). If you're happy, then I can re-run the import and add these to the Subversive repo directly.
@mward Thanks, it looks alright, I could live with it
