On Tue, Jan 25, 2000 at 07:17:31PM -0500, Federico Mena Quintero
<[EMAIL PROTECTED]> wrote:
> People should feel free to ask for a CVS account on the cvs.gnome.org
> box. If they have something cool they are working on for the GIMP, we
As a matter of fact, it is very difficult ot get a cvs account, for
various reasons. We do not want to have every plug-in author have writing
rights to the gimp tree, but we _do_ want every plug-in author to have
For other reasons, giving them access to a "shielded cvs" could be done
much easier (just let him prove he can do it), than having to persuade a
lot of people to get a cvs account (for good reasons).
On Tue, Jan 25, 2000 at 06:37:17PM -0600, Dean Johnson <[EMAIL PROTECTED]> wrote:
> I guess I wasn't advocating moving the whole tree over, just the plug-ins.
No, the way it'l be done is to mirror the whole tree, so people can
just check out the _whole_ gimp from sourceforge, and work in it. The
difference to the anonymous server is that they can write to the cvs, but
they will not be able to change any files not marked for changing.
On Wed, Jan 26, 2000 at 01:24:44AM +0100, Sven Neumann <[EMAIL PROTECTED]>
> this into account from the beginning and split the tree from ground up.
> This means having two branches (stable and devel) on the plugin CVS. That
I think we should just do the same as we do on the main cvs server: once
1.2 is out, make a 1.2 branch, do the same on the plug-ins server.
> them later out of the 2.0 compatible plug-in branch. However I haven't
> thought much about this yet, is it a good idea ...?
I haven't thought about that myself, but having two barnches (then) makes
very much sense to me. The mirror script would be almost the same.
> I also want to point out that IMHO setting up a CVS server will not be
SourceForge gives us all that, web, ftp, cvs etc.. As a matter of fact,
there already is a sourceforge project named "gimp-plug-ins" since a few
My (better thought-pout plan) is to add these two files to the main gimp cvs:
PLUGIN_CVS # control what gets mirrored, when
ChangeLog.plug-ins # the changes for the plug-in tree
the first one declares some files/directories to be part of the "plug-ins"
> enough. Ideally, this project should completely replace the registry.
> A web interface to the repository together with tips for installation
> will be essential. Plug-ins should be released on a regulary basis,
> since working with stuff out of CVS is not what our users want to do
> and it always buries the risk of checking stuff out that just doesn't
> work at the moment.
I fully support this. Alas, it's much work, so I suggest that I first
create the project, add the mirroring (so the cvs is functional) and then
gather _existing_ plug-in maintainers without cvs access to find out
wether they want an account on ther sourceforge net.
After that, some files (i.e. the "externally managed" plug-ins) are
read-only in the main cvs tree, and writable in the plug-in cvs tree, and
all the rest is read-only in the plug-in cvs, and read-write in the main
This is the only solution that makes it possible to do automatic merges
back into the main tree. It also complicates things for the main
developers, so it should be given thought (in any case, the mirror
script that I have allows to specify "file in original server", "file in
copied/plug-in server" and "file is not getting mirrored" (i.e. it's part
of gimp-plug-in-cvs but NOT part of the main gimp tree).
[before you misunderstand the above paragraph, ask!]
If this is in place we/I should seek out for help to get more automatic
registrations etc.. (i.e. registering plug-in "space", having nicer
Having a seperately managable tree would it also make it possible to
experiment with new ways of plug-in distribution, binary packages etc..
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |