On Oct 23, 2007, at 2:41 PM, Stephen Sinclair wrote:
are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Actually, it would be good if you did push the idea. :D I think if we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.
From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.
For example, GNU Arch says on the first page (http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".
.hc
Steve
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.