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

[Eric V. D. <erv...@gm...>]

Regarding eclim, now that I'm on the mailing list I can answer any
specific questions you guys may have.

On 10/16/07, Sebastian Menge <s....@gm...> wrote:
> Am Tue, 16 Oct 2007 19:36:24 +0200 schrieb Martin Krischik:
>
> > I think it's a cool idea.
>
> Absolutely. It is definitely worth looking into. Eclipse
> codecompletion inside an embedded vim would be exactly what we all are
> looking for, I guess :-)
>
> I have checked out eclim myself to try some experiments on it, but did
> not manage to get it run by now ;-) Are there any notes how the
> project is being built ?
>
>
> > Well, in the project I am Admin I see these things rather relaxed.
>
> Whereever ppl come together to build something up, there are rules
> (call it laws, good/bad behavior, etiquette, whatever): some are
> implicite, some not. If conflicts arise, the conclusion should be a
> new rule such that ppl learn to work together constructively.
>
> The classical example is quoting in mailing lists: If the majority of
> ppl are annoyed by a certain kind of quoting they will express that
> someday. Then the community will decide what will be best. This is in
> fact a kind of democratic decision making.
>
> The SVN-Repository is our main development spot. We need to keep it
> tidy and in good order.  Edward complained that it is not in good
> order and I must say that my personal opinion (which is just one of
> many) is along Edwards. The mere comparison of directory sizes [1]
> tells me that there is something out of balance.
>
> If there is no better way than copying a whole other repository, I (again
> myself) would at least ask whether other team-members have objections,
> before importing something that is 30 times as large as the main trunk.
> But hopefully the others will come up with better ways.
>
> Now that it has happened, we should look forward for ways how to deal
> with it. I would propose the following (since I _really_ like the
> idea to use eclims features in our context, please keep it going!):
>
>   * we should develop experiments locally.
>   * when something useful comes out (e.g. a non-headless eclim server,
>     as a first step), create patches (which is fairly easy with eclipse:
>     "Team|Create Patches" in the context menu of a project)
>   * publish patches here and to eclims developer(s)
>   * discuss patches a bit
>   * if the patches look promising but changes are too big, create branch
>     for it
>
> So the general "rule" I would like to extract from this is simple:
>
>   "Before doing any large scale operations that potentially affect
>   others, discuss/ask about it on the mailing list."
>
> But as I said, this is a free project, and the other members should
> say what they think (e.g. it could be an option to say: Everything
> under "branches" can be used at free will.).
>
> Best regards, Sebastian.
>
> [1] some directory sizes:
> trunk: 1,9MB
> tags: 7,6MB (some old releases)
> branches/eeedit 1,5MB
> branches/eeedit-import 5,0MB
> branches/gvimplguin 1,8MB
> branches/vimclient 1,6 MB
> branches/eclimplguin 61MB (21 formic, 38 eclim)
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> vimplugin-devel mailing list
> vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimplugin-devel
>


-- 
eric