Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Martin K. <kri...@us...>]

Am Montag 15 Oktober 2007 schrieb Sebastian Menge:

> Hi Edward,
>
> I'm sorry you have problems with the repo.
>
> Am Mon, 15 Oct 2007 16:55:38 +0800 schrieb Edward L. Fox:
>
> Martin committed a lot of things into a branch called eclimplugin.
>
> Martin, could you explain your plan to us, and perhaps figure out a
> better way?

You might know about the eclim project [1]. It does the opposite of what we=
 do=20
here: You use Vim to remote controll an Eclipse server. That is: Vim is the=
=20
master and Eclipse is the slave.

This has the advantage that Eclipse functions are available in=20
Vim. ":ProjectSettings" for example would open the projects setting's in vi=
m.=20
But the killer features are integration of code completion, code correction=
=20
and quickfix. I might have missed something - but I have not seen anything =
in=20
that direction in our project.

However, Eclim has an all or nothing approach: You don't have Ecliplse at a=
ll=20
visible and any feature not yet communicated is not available. Now I think=
=20
that is a rather drastic approach.

Now my idea is to start the Eclim server by gvimplugin when the first GVim =
is=20
opened. The freshly started GVim can then call back and make all the nice=20
Eclim features available.

I think it's a cool idea.=20

> In general I would suggest to d
> 1) do some local experiments and=20

Without off site backup? That's one of the reasons I use SourceForge: If=20
something bad is happening to either me or my computer the work is not lost.

> 2) publish  a working prototype to a private website and

Well, thought that is one of the things for what branches are for: Keeping =
a=20
experiments separate from the rest of team until they are ready.

> 3) ask the other developers=20
> whether or how it could be merged into the main trunk...  (perhaps it's
> worth a new project ..)

Right on. Only a separate project would not work all that well, for the pla=
n=20
to work one need both parts.

> Would it perhaps be clever to develop some "social rules" how we want to
> run the project? Any proposals?

Well, in the project I am Admin I see these things rather relaxed. But then=
 in=20
none of the other projects we have a commit mailing list or a team member w=
ho=20
need to mirror the whole repository...

Martin

[1] http://eclim.sourceforge.net/

=2D-=20
Martin Krischik
mailto://kri...@us...