Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for

Jehan Pagès writes:
[on one repo per asset vs. one repo containing many assets]
Really I don't understand this point which Akkana is raising. Has
anyone ever made plugins for various software? I have, for a bunch,
many dead now, some still living. And never have I ever thought "oh
let's put all my completely unrelated plugins into the same
repository"! This is like the base of code organization, you just have
separate items. I have a bunch of repositories of my own, and have a
few dozens of repositories from various projects which I have needed
at some point.

In the current GIMP source tree, circuit.scm,clothify.scm,
coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and
spyrogimp.scm (I just picked a random set) are all completely
unrelated scripts. Yet there they all are, 53 different .scm files
in the GIMP source repository in the plug-ins/script-fu/scripts/
directory, and similar unrelated collections in
plug-ins/pygimp/plug-ins/ and plug-ins/ itself.

You are arguing that it's easier/better to maintain unrelated assets
each in its own repository. But evidently the GIMP development team
agrees with me: they have and a bunch of unrelated script files
together within one directory within one big repository. That's how
I organize my GIMP plug-ins too, and it's the model used in every
other software project I've been involved with.

Maybe I'm just being old fashioned because "many files in one big
repo" is the only model I've seen in action. From what you say, I
guess I should look at Wordpress to see a project that uses "one
repo per file" successfully?

I'm still not clear what the advantage would be of one repo per
file. The disadvantages I see: many small repos are slower to check
out, are more work to maintain, have a (slightly) bigger disk
footprint, and you have to write a script to make sure you've pulled
everything you need. Plus possibly Pat's concern about gitlab not
allowing that many repos, but we don't know the answer to that yet.

But if this is just for the backend, and individual asset developers
will have some way of submitting a single file and don't ever have
to check out all those little repos, then I guess all that really
matters is what makes the most sense to the registry development
team. (And I hope I can be part of that team and help in some way,
regardless of what decision you make about the number of repos.)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]