infra-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Sitnikov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (INFRA-18499) Migrate primary VCS from SVN to Git for Apache JMeter
Date Tue, 04 Jun 2019 05:33:00 GMT

    [ https://issues.apache.org/jira/browse/INFRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855337#comment-16855337
] 

Vladimir Sitnikov edited comment on INFRA-18499 at 6/4/19 5:32 AM:
-------------------------------------------------------------------

{quote}I am unsure as to why a secondary repo is needed. This to me is the biggest cause for
concern. Was the jmeter-git-cleanup repo for demonstration purposes only?{quote}

I'm not sure what you mean by staging repo.

https://github.com/vlsi/jmeter-git-cleanup is a repository to hold a cleanup script.
The cleanup itself is two scripts: run.sh (it clones from https://github.com/apache/jmeter.git)
and keep_blob (it is a set of blob ids to keep which otherwise would be removed by bfg).

Note: cleanup script performs {{git remote set-url origin https://github.com/vlsi/jmeter-git-cleanup-result.git}},
however it is there only to prevent accidental push to apache/jmeter repository.

https://github.com/vlsi/jmeter-git-cleanup-result is a "preview repo" with cleanup result.
It is there just for evaluation purposes.

I think we don't need apache/jmeter-cleanup.git


{quote} I'm unsure as to how this is intended to be run during the migration{quote}
One runs ./run.sh locally. The script clones apache/github repo, and removes irrelevant blobs.
Then the resulting repository can be pushed to apache/jmeter directly (provided it won't produce
mail notifications for all the commits)

{quote} It adds complexity to something that is already very complicated to begin with{quote}
Thanks, however I would slightly disagree. The cleanup itself is just a single BFG pass.

{quote}If those tags and branches are not "release" tags/branches, they would not be protected
in git, and could be deleted at any time. {quote}
I see.



was (Author: vladimirsitnikov):
{quote}I am unsure as to why a secondary repo is needed. This to me is the biggest cause for
concern. Was the jmeter-git-cleanup repo for demonstration purposes only?{quote}

I'm not sure what you mean by staging repo.

https://github.com/vlsi/jmeter-git-cleanup is a repository to hold a cleanup script.
The cleanup itself is two scripts: run.sh (it clones from https://github.com/apache/jmeter.git)
and keep_blob (it is a set of blob ids to keep which otherwise would be removed by bfg).

Note: cleanup script performs {{git remote set-url origin https://github.com/vlsi/jmeter-git-cleanup-result.git}},
however it is there only to prevent accidental push to apache/jmeter repository.

https://github.com/vlsi/jmeter-git-cleanup-result is a "preview repo" with cleanup result.
It is there just for evaluation purposes.

{quote} I'm unsure as to how this is intended to be run during the migration{quote}
One runs ./run.sh locally. The script clones apache/github repo, and removes irrelevant blobs.
Then the resulting repository can be pushed to apache/jmeter directly (provided it won't produce
mail notifications for all the commits)

{quote} It adds complexity to something that is already very complicated to begin with{quote}
Thanks, however I would slightly disagree. The cleanup itself is just a single BFG pass.

{quote}If those tags and branches are not "release" tags/branches, they would not be protected
in git, and could be deleted at any time. {quote}
I see.


> Migrate primary VCS from SVN to Git for Apache JMeter
> -----------------------------------------------------
>
>                 Key: INFRA-18499
>                 URL: https://issues.apache.org/jira/browse/INFRA-18499
>             Project: Infrastructure
>          Issue Type: SVN->GIT Migration
>          Components: GitBox, Subversion
>            Reporter: Vladimir Sitnikov
>            Priority: Major
>
> There's an agreement to migrate from SVN to GitBox for Apache JMeter.
> Here's the vote thread: https://www.mail-archive.com/dev@jmeter.apache.org/msg13085.html
> One of the ideas is to cleanup Git repository as a part of migration (e.g. remove accidentally
committed multi-megabyte jar files)
> Can you please clarify if that is a viable approach?
> My understanding is that it is valid to alter history (e.g. remove unrelated files) during
SVN->Git migration.
> Note: I do understand that "GitHub pull requests will need to be rebased", so the question
is more like "are there limitations on history edits during migration?"
> Current SVN: https://svn.apache.org/repos/asf/jmeter
> Desired Git: https://github.com/apache/jmeter
> "git cleanup" is an automatic script: https://github.com/vlsi/jmeter-git-cleanup/blob/4cb08789bd70eb61f77e94fbebc32974ea6da215/run.sh
> The result is as follows: https://github.com/vlsi/jmeter-git-cleanup-result
> As far as I understand, the process is as follows:
> * JMeter committers settle on a timeframe so they do not commit to SVN/Git repositories
> * Infra disables SVN->Git sync
> * Infra disables mail notifications for https://github.com/apache/jmeter
> * Infra makes SVN repository a read-only one
> * Infra (or someone from JMeter comitters?) populates https://github.com/apache/jmeter
> * Infra enables mail notifications for https://github.com/apache/jmeter



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message