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

[Sebastian M. <s....@gm...>]

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)