New plugin: rename-project

[Chad Horohoe]

Hi,

We're working on a new plugin to rename projects, and it's ready

for its own repository. Can I have a new plugin repository called

"rename-project?" Thanks!

-Chad

[Saša Živkov]

On Wed, Feb 6, 2013 at 1:12 PM, Chad Horohoe <chor...@wikimedia.org> wrote:

Hi,

We're working on a new plugin to rename projects, and it's ready

Hmm... in Gerrit core we already have: create-project and set-project commands.

So, we can create projects and change project settings using these commands.

Wouldn't it feel strange if for renaming of a project one needs a plugin.

I am not against the rename-project plugin but, eventually, it would be nice to

have this functionality in Gerrit core.

 

for its own repository. Can I have a new plugin repository called

"rename-project?" Thanks!

-Chad

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thomas Broyer]

On Wednesday, February 6, 2013 1:32:16 PM UTC+1, zivkov wrote:

On Wed, Feb 6, 2013 at 1:12 PM, Chad Horohoe <chor...@wikimedia.org> wrote:

Hi,

We're working on a new plugin to rename projects, and it's ready

Hmm... in Gerrit core we already have: create-project and set-project commands.

So, we can create projects and change project settings using these commands.

Wouldn't it feel strange if for renaming of a project one needs a plugin.

I am not against the rename-project plugin but, eventually, it would be nice to

have this functionality in Gerrit core.

Well, the same could be said for deleting a project, yet there's a plugin for that: https://gerrit.googlesource.com/plugins/delete-project/

+1 for a rename-project command though, whether it's a plugin or in core I don't mind.

[Saša Živkov]

On Wed, Feb 6, 2013 at 4:09 PM, Thomas Broyer <t.br...@gmail.com> wrote:

On Wednesday, February 6, 2013 1:32:16 PM UTC+1, zivkov wrote:

On Wed, Feb 6, 2013 at 1:12 PM, Chad Horohoe <chor...@wikimedia.org> wrote:

Hi,

We're working on a new plugin to rename projects, and it's ready

Hmm... in Gerrit core we already have: create-project and set-project commands.

So, we can create projects and change project settings using these commands.

Wouldn't it feel strange if for renaming of a project one needs a plugin.

I am not against the rename-project plugin but, eventually, it would be nice to

have this functionality in Gerrit core.

Well, the same could be said for deleting a project, yet there's a plugin for that: https://gerrit.googlesource.com/plugins/delete-project/

 

I was aware of the delete-project plugin and I think it should also become

a part of Gerrit core. It is unintuitive that we can create a project in Gerrit

but need a plugin to delete it.

Hmm.. a reason to prefer working on a plugin project instead on Gerrit core

may be that it is simply faster because it is a different set of people with the

Code-Review+2 permission?

This way, a plugin project could be considered a topic branch with a different

set of access permissions ;-)

+1 for a rename-project command though, whether it's a plugin or in core I don't mind.

--

[Chad Horohoe]

On Wed, Feb 6, 2013 at 11:30 AM, Saša Živkov <ziv...@gmail.com> wrote: 

I was aware of the delete-project plugin and I think it should also become

a part of Gerrit core. It is unintuitive that we can create a project in Gerrit

but need a plugin to delete it.

Hmm.. a reason to prefer working on a plugin project instead on Gerrit core

may be that it is simply faster because it is a different set of people with the

Code-Review+2 permission?

This way, a plugin project could be considered a topic branch with a different

set of access permissions ;-)

It's easier to update a plugin than core in your installation (just drop

the jar in). I'm in favor of making *more things* as plugins.

-Chad

[Brad Larson]

I agree with Chad, there are a few benefits of plugins from a development side versus putting everything in core (besides more review permissions) -

Out of band updates

No need to make everyone happy (the delete plugin is a great example of this - nobody could agree on what delete project should do, but if we put it in a plugin it doesn't matter.  If you want it to archive rather than delete, use to code to create an archive plugin)

Less concerns about breaking things - plugins are fairly well sandboxed, and if they don't work just uninstall them

There are definitely some downsides to plugins from the user's perspective -

Plugin discoverability (and installation) is hard

Some features which complement features in core are odd to have as plugins (like Saša points out with create project vs rename/delete)

I think we can solve these issue though - for issue 2, long term it'd be nice to have some statistics on what plugins users install (perhaps an opt-in system for automated reporting?  See Jenkin's usage graph: https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger)

If a plugin is used by 90% of users, maybe we should move the logic to core or bundle the plugin with the core distribution?

Sorry I'm starting to ramble here... but just my $0.02.

Brad

[Edwin Kempin]

I've created the plugin project for implementing project rename [1].

I agree with Sasa that project deletion / project rename is some functionality that longterm we would like to have in Gerrit core.
On the other side I see how doing it as a plugin makes it easier to get started. When the plugin is mature enough we can still move the code to Gerrit core.

[1] https://gerrit-review.googlesource.com/#/admin/projects/plugins/rename-project

2013/2/6 Brad Larson <bkla...@gmail.com>

--

[Chad Horohoe]

I should've responded to the list--we all agreed on IRC that core

is best and we're just going to pursue that instead of a plugin :\

-Chad

[Saša Živkov]

On Wed, Feb 6, 2013 at 8:32 PM, Brad Larson <bkla...@gmail.com> wrote:

On Wednesday, February 6, 2013 11:05:01 AM UTC-6, Chad Horohoe wrote:

On Wed, Feb 6, 2013 at 11:30 AM, Saša Živkov <ziv...@gmail.com> wrote: 

I was aware of the delete-project plugin and I think it should also become

a part of Gerrit core. It is unintuitive that we can create a project in Gerrit

but need a plugin to delete it.

Hmm.. a reason to prefer working on a plugin project instead on Gerrit core

may be that it is simply faster because it is a different set of people with the

Code-Review+2 permission?

This way, a plugin project could be considered a topic branch with a different

set of access permissions ;-)

It's easier to update a plugin than core in your installation (just drop

the jar in). I'm in favor of making *more things* as plugins.

-Chad

I agree with Chad, there are a few benefits of plugins from a development side versus putting everything in core (besides more review permissions) -

 

This is not a discussion on whether plugins are good or not.

We all like the plugin concept, including myself. I even implemented one :-)

I was only wondering, in this particular case, what is the main reason

to implement the 'rename-project' as a plugin instead of a core command?

Out of band updates

No need to make everyone happy (the delete plugin is a great example of this - nobody could agree on what delete project should do, but if we put it in a plugin it doesn't matter.  If you want it to archive rather than delete, use to code to create an archive plugin)

Less concerns about breaking things - plugins are fairly well sandboxed, and if they don't work just uninstall them

Plugins have access to Gerrit internals.

They can modify data in the DB and Git repositories and they can corrupt them.

[Brad Larson]

Of course that is true - 'sandbox' was probably too strong of a word.  I just meant that I've always felt more comfortable writing a feature as a plugin compared to touching MergeOp or modifying other internals.

[Saša Živkov]

What is really sandboxed is the plugins guice environment so that plugins

cannot (accidentally or intentionally) define a (just in time) binding that would

be visible by Gerrit server or other plugins.

I just meant that I've always felt more comfortable writing a feature as a plugin compared to touching MergeOp or modifying other internals.

This is understandable because plugins are called from well-defined

extension points while, to modify Gerrit core, one needs to understand a lot

more context.

 

There are definitely some downsides to plugins from the user's perspective -

Plugin discoverability (and installation) is hard

Some features which complement features in core are odd to have as plugins (like Saša points out with create project vs rename/delete)

I think we can solve these issue though - for issue 2, long term it'd be nice to have some statistics on what plugins users install (perhaps an opt-in system for automated reporting?  See Jenkin's usage graph: https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger)

If a plugin is used by 90% of users, maybe we should move the logic to core or bundle the plugin with the core distribution?

Sorry I'm starting to ramble here... but just my $0.02.

Brad

[Deniz Türkoglu]

Coming back to this now. We now have a rename-project plugin that has no commits or reviews, ironically can we delete it if we are not going to use it?

Also, the reason I am bringing back this thread, we need this functionality now, it might looks easy, just move the dir and update the database and yet I guess there might be tricky stuff coming up later on.

@chad Can you please shed some light on? :)

-deniz

[Chad Horohoe]

On Thu, Sep 19, 2013 at 11:07 AM, Deniz Türkoglu <de...@spotify.com> wrote:

Coming back to this now. We now have a rename-project plugin that has no commits or reviews, ironically can we delete it if we are not going to use it?

Also, the reason I am bringing back this thread, we need this functionality now, it might looks easy, just move the dir and update the database and yet I guess there might be tricky stuff coming up later on.

@chad Can you please shed some light on? :)

Never got around to implementing it as a plugin, there's a fair bit

of unmerged work for core that does it.

https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:rename-project,n,z

It's not on either mine or Christian's todo list at the moment, but I

sure wouldn't mind seeing the changes dusted off and getting some

traction.

-Chad 

[Deniz Türkoglu]

Getting such a change to core will take a long time, at least it used to, maybe it's better now? Anyway, now we have patches that  don't merge and needs to be rebased.

I actually think converting them to a plugin, sans UI, might be a better idea to not let that work go to waste.

[Mark Derricutt]

Resurrecting this old thread as I just looking for how to rename a project, found the (still existing) empty rename-plugin project and then this thread, and found the topic that's untouched since September 2013, and as you say, can't merge now.

Did this ever get moved to a plugin somewhere?  If not, I'm tempted to rebase this topic onto the current codebase ( not that I know much of the code base myself ).

[Doug Kelly]

Funny you should mention this.  I actually had to handle one of these the other day by hand.  There's four main steps that I found (all can be done online, amazingly):

1) Move the project. This is pretty obvious, as most things are stored in refs/meta/config related to the project.

2) Update the "dest_branch_name" in the changes table. (If you use submodule subscriptions or have people watching the project, those may need to be updated here to keep working as well, but it's not 100% critical for purposes of this exercise.)

3) Flush caches (at least projects, projects_list, permission_sort, and changes, I think).

4) Reindex any changes (if you use a secondary index that's not SQL) that were on the project (maybe select the list of change ids from the changes table while you're doing the DB magic).  This one is kinda tricky, but here's the basic idea (thanks to David Borowitz for pointing it out):

curl -n -k -X POST --digest https://gerrit-server/a/changes/12345/index

Note that the command assumes you have a .netrc file set up with your HTTP password configured.  The command must be run once for every change.  The alternative here would be to shut Gerrit down and run "gerrit reindex" -- but that's like using artillery to kill a fly.  It does eliminate the need to flush caches as well, though.

--Doug

[Christian Aistleitner]

Hi Mark,

On Wed, Apr 02, 2014 at 03:25:53PM -0700, Mark Derricutt wrote:
> Did this ever get moved to a plugin somewhere?

Not that I am aware of.

Putting it into a separate plugin sounds tricky. Back then you needed
to touch some internals to ensure proper locking during some
operations. That'll be hard from a plugin.

> If not, I'm tempted to
> rebase this topic onto the current codebase ( not that I know much of the
> code base myself ).

Feel free to pick up the changes I did back then. Most of them are a
bit big, but size is mostly due to the added tests. I doubt that the
topic's changes still work (or are still sufficient) as is.

But if some parts seem unmotivated or arcane, I'll gladly try to
explain either here on-list, in gerrit, or off-list.

Best regards,
Christian


--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a Email: chri...@quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------