Menu
▾
▴
vimplugin-devel
|
From: Edward L. F. <ed...@gm...> - 2007-10-15 08:55:37
|
Hi all, I had begun to mirror the SVN repository to my local SVK repository since the day before yesterday. But up till now, the mirroring is still in progress, at revision 141. I have to admit that the SVN service on SF.net is a bit too *slow* to me. I also tried to mirror the repository from the latest revision, by passing all the former revisions, but it was still quite slow. I briefly browsed around the repository and found that a lot of third-party jar archives, generated binary files and many sorts of things was mistakenly committed into the repository. So I just think, is there any way to erase all the history from the repository and re-create a brand new clean repository? I really can't start my work in current situation. Best regards, Edward Fox |
|
From: Martin K. <kri...@us...> - 2007-10-15 17:04:06
|
Am Montag 15 Oktober 2007 schrieb Edward L. Fox: > I had begun to mirror the SVN repository to my local SVK repository > since the day before yesterday. But up till now, the mirroring is > still in progress, at revision 141. I have to admit that the SVN > service on SF.net is a bit too *slow* to me. I also tried to mirror > the repository from the latest revision, by passing all the former > revisions, but it was still quite slow. Why would you want to mirror the whole repository? To me that seems to be a= n=20 overkill. > I briefly browsed around the repository and found that a lot of > third-party jar archives, generated binary files and many sorts of > things was mistakenly committed into the repository. So I just think, > is there any way to erase all the history from the repository and > re-create a brand new clean repository? I really can't start my work > in current situation. Maybe - but it seems a lot of work. Also we loose other interesting options= =2E I=20 for once backup my PMWiki's into SourceForge - which too take up space. Martin =2D-=20 Martin Krischik mailto://kri...@us... |
|
From: Sebastian M. <s....@gm...> - 2007-10-15 18:08:09
|
Hi Edward, I'm sorry you have problems with the repo. Am Mon, 15 Oct 2007 16:55:38 +0800 schrieb Edward L. Fox: > I had begun to mirror the SVN repository to my local SVK repository > since the day before yesterday. But up till now, the mirroring is still > in progress, at revision 141. I have to admit that the SVN service on > SF.net is a bit too *slow* to me. I also tried to mirror the repository > from the latest revision, by passing all the former revisions, but it > was still quite slow. Is it slow is it too much data? One only needs the trunk ... no branches or tags ... I have absolutely no performance probs here. Why do you need to mirror the whole repo? > I briefly browsed around the repository and found that a lot of > third-party jar archives, generated binary files and many sorts of > things was mistakenly committed into the repository. So I just think, > is there any way to erase all the history from the repository and > re-create a brand new clean repository? I really can't start my work in > current situation. 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? In general I would suggest to 1) do some local experiments and 2) publish a working prototype to a private website and 3) ask the other developers whether or how it could be merged into the main trunk... (perhaps it's worth a new project ..) Would it perhaps be clever to develop some "social rules" how we want to run the project? Any proposals? Sebastian. |
|
From: Martin K. <kri...@us...> - 2007-10-16 18:03:36
|
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... |
|
From: Sebastian M. <s....@gm...> - 2007-10-17 00:14:35
|
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)
|
|
From: Eric V. D. <erv...@gm...> - 2007-10-17 00:21:31
|
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 |
|
From: Sebastian M. <s....@gm...> - 2007-10-17 00:44:22
|
Am Tue, 16 Oct 2007 17:21:28 -0700 schrieb Eric Van Dewoestine: > Regarding eclim, now that I'm on the mailing list I can answer any > specific questions you guys may have. > >> Are there any notes how the project is being built ? hehe, this one was meant for you :-) Seb. |
|
From: Eric V. D. <erv...@gm...> - 2007-10-17 01:28:37
|
Are you referring to how to build it (compile, deploy, etc.) or are you asking about the architecture? On 10/16/07, Sebastian Menge <s....@gm...> wrote: > Am Tue, 16 Oct 2007 17:21:28 -0700 schrieb Eric Van Dewoestine: > > > Regarding eclim, now that I'm on the mailing list I can answer any > > specific questions you guys may have. > > > >> Are there any notes how the project is being built ? > > hehe, this one was meant for you :-) > > Seb. > > > ------------------------------------------------------------------------- > 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 |
|
From: Sebastian M. <seb...@un...> - 2007-10-17 08:06:18
|
Am Tue, 16 Oct 2007 18:28:40 -0700 schrieb "Eric Van Dewoestine" <erv...@gm...>: > Are you referring to how to build it (compile, deploy, etc.) or are > you asking about the architecture? I just want to compile and run it: how do I have to configure project settings (e.g. dependency of formic), howto build it etc ... Things are a bit different in contrast to standard plugins since you define a whole new (headless) eclipse-app. BTW great to have you on the list ... :-) Seb. |
|
From: Eric V. D. <erv...@gm...> - 2007-10-17 14:20:45
|
Note: the ant scripts for building eclim are not setup to run on windows.
Before building eclipse you will need to:
- set the environment variable ECLIPSE_HOME which points to your
eclipse install
- make sure you install the required eclipse features
- wst (2.0.x)
- pdt (1.0.0 final)
Also note that the eclim build files assume that your vimfiles
directory is located at ~/.vim
Once your environment is setup you should then just need to run '$
ant' from the top level directory of the eclim code base. From there,
starting and stopping eclim is the same as if you had installed it via
the installer.
It's been a while since I've setup a fresh development environment for
eclim, so it's possible there is something I'm missing, but hopefully
that should be it.
As for formic, that is only needed if you plan on building the
installer (apache forrest would be needed as well).
> BTW great to have you on the list ... :-)
Happy to be here.
On 10/17/07, Sebastian Menge <seb...@un...> wrote:
> Am Tue, 16 Oct 2007 18:28:40 -0700
> schrieb "Eric Van Dewoestine" <erv...@gm...>:
>
> > Are you referring to how to build it (compile, deploy, etc.) or are
> > you asking about the architecture?
>
> I just want to compile and run it: how do I have to configure project
> settings (e.g. dependency of formic), howto build it etc ...
>
> Things are a bit different in contrast to standard plugins since you
> define a whole new (headless) eclipse-app.
>
> BTW great to have you on the list ... :-)
>
> Seb.
>
> -------------------------------------------------------------------------
> 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
|
|
From: Martin K. <kri...@us...> - 2007-10-17 18:03:52
|
Am Mittwoch 17 Oktober 2007 schrieb Sebastian Menge: > Am Tue, 16 Oct 2007 18:28:40 -0700 > > schrieb "Eric Van Dewoestine" <erv...@gm...>: > > Are you referring to how to build it (compile, deploy, etc.) or are > > you asking about the architecture? > > I just want to compile and run it: how do I have to configure project > settings (e.g. dependency of formic), howto build it etc ... You could check out my branch - it actually compiles ;-) as it allready=20 containts formic and the classpath has been fixed with the current version= =20 numbers. Of course I welcome improvements. For example there are .jar files checked= =20 in - but for each jar removed from the repository we should have note on th= e=20 wiki how to obtain it.=20 Speaking of the Wiki: what's the password? > Things are a bit different in contrast to standard plugins since you > define a whole new (headless) eclipse-app. > > BTW great to have you on the list ... :-) Yes indeed, nice to see you here. Martin =2D-=20 Martin Krischik mailto://kri...@us... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X