Page 1 of 1

CVS write access?

Posted: Wed Oct 16, 2002 8:36 pm
by voidptr
Now that we are getting the source to build, but with changes I think it would be good to start thinking of CVS write access or at least patch submit methods. Otherwise we are going to see too many versions of the same work stored on individual servers. A fork at this point would be a bad thing.

Just a thought.


Posted: Wed Oct 16, 2002 8:42 pm
by beergeek
Agreed. I vote for a patch mailing list. Ton (and others who have write access) can then review the patches individually and apply them as they see fit. Until that is setup maybe we should post patches to one of the forums.

Posted: Thu Oct 17, 2002 1:30 am
by Charlls

that is the quickest way to fork Blender, what are going to do ppl with a lot of patches that doesnt know what they do unless they install it???? do you _think_ ppl are going to install 8, 9 versions of Blender??

there CANNOT be "patches" , "thingies", or even worse, "hacks", when ppl talk about "hacking" and "patching" when they got source, i think of crappy, unmaintanable code who no one wants to read

so, all ppl who want to contribute code _TO THE CVS_ they should ask Ton for a cvs account, but before that Ton should tell us how are we going to get cvs write access. If a commit isnt meaningful to the Blender developing goals, Ton and whoever has cvs keys can revert those changes


:evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil: :evil:

Posted: Thu Oct 17, 2002 2:15 am
by voidptr

I agree. Please don't place patches in the forums. This will hurt more than help.

That's why Ton, et al. should start a method to add CVS write or a central patch --> release method. If we are all running around try {change, patch, post, bitch, patch, change, post} we get nowhere.

Right now I think there are 5 - 6 different build methods, this is bad.

We should have one base with stable & devel trees. That is not going to happen with 40 people listing their own source tree at there own site around the world.

I think the biggest problem is that we all underestimated the resourcefulness of some people. Plus the shear number of people in this community cought everyone off guard from the very start.

The enthusiasm to build on blender here is great. I just hope we can build a community were everyones ideas aren't lost in the shuffle.

And please no yelling. It's not helpful to get worked up.


Posted: Thu Oct 17, 2002 2:29 am
by Charlls
heh sorry for the yelling, but i was starting to feel like no one was hearing :)

ok, most open source projects work around two main methodologies:

a) Project leader splits a series of tasks, post them somewhere and ppl start taking them

b) if someone wants to contribute consistently, he/she go and ask Ton for a write account, and commit his modifications. If this somehow breaks the cvs, changes can always be reverted, but this only will happen if the commiter doesnt fix it

here goes an idea to improve development efficiency: create a plugin infrastructure for Blender. Currently plugins only cover procedural textures, but if plugins achieve the same amount of integration that python (intends to) have ie: geometry materials menu creation etc. then developers of plugins only need to implement the interfaces to the plugins, which should be esentially abstract c++ classes, but i havent looked yet how proctex plugins are done right now in Blender

Posted: Thu Oct 17, 2002 2:50 am
by IngieBee
Cool idea, I like that idea alot. Thanks

Posted: Thu Oct 17, 2002 3:39 am
by beergeek

I am sorry I think I was a little unclear about the way I envisioned things working. First, The end user should NEVER have to apply a patch or build anything. There should be only one blender available from in binary format (and source for those interested).

In most open source projects only a small group of people have CVS write access. This means that in order for people to contribute to the project they have to send a patch to someone with write access. Right now there is no formal way to do that. What I proposed above was simply a way for those without cvs write access to contribute to the source base (Each patch would be reviewed by Ton et all and either accepted or rejected). After someone submits a lot of good patches they could eventually get cvs write access.

I have a feeling things will calm down there will be a system to get the build systems and patches that are floating around together and under one binary/source/cvs release. Things are just a little hectic now. In a week or two thing will calm down and really start moving forward.

Posted: Thu Oct 17, 2002 4:18 am
by Charlls
total agree :D


Posted: Fri Oct 18, 2002 4:28 pm
by ton
I've posted an article on CVS write access yesterday. We'll provide a (temporal) new tree to experiment on.
A few people now are testing. Hopefully today we'll contact several people who've contributed useful stuff here to join.
(Everyone then can access it for read)

First goal is only at a 'project management' level. Getting Blender ready for easy cross platform development. And especially working like it did before. :)

Posted: Fri Oct 18, 2002 5:12 pm
by LarstiQ
I agree with beergeek, at least for now, we can always see what to do later on. Wine has a wine-patches mailing list where people send patches to, everyone can comment on those patches (usually done on the discussion list wine-devel), update, etc. Only one person (Alexandre Julliard) actually has cvs access afaik, he checks the patches for quality, coding style, usefulness etc, and periodically commits patches. Wine-cvs (the commit log mailing list) lists 249 commited patches for this month, so wine people are fairly busy :)

This clearly does not mean every user should patch themselves, and with big issues (say, a new render backend) people will still need to work together, but imho this is a good way to keep cvs sane and controlled, yet still make development fairly low-entry.

If most or all of the active developers have cvs commit access the need for this becomes a bit less, but it still is good to have it for people who write the occasional patch but don't have write permissions, at the very least it is clear where one should send patches to.

Archives and other stuff on the wine mailing list:

Posted: Fri Oct 18, 2002 6:36 pm
by leinad13
It sounds like a good idea to me

Posted: Sat Nov 02, 2002 9:07 am
by WL
Everyone makes some really good points here. I don't think only having one person with cvs access is very efficient, but here's a link to how cvs access, review, super-review and source changes work on the Mozilla project- I think it would provide a good model. I've been helping out on that project for a few months, and their system seems to work very well for keeping the code buildable, especially given that it's a huge codebase on multiple platforms.

Plus, is interesting because it could provide some useful tools: bugzilla, tinderbox, bonzai, LXR...

Posted: Sat Nov 02, 2002 2:18 pm
by nlin
WL wrote:Everyone makes some really good points here. I don't think only having one person with cvs access is very efficient, but here's a link to how cvs access, review, super-review and source changes work on the Mozilla project- I think it would provide a good model.
A better model, IMHO, is that provided by Aegis (, which has been around for more than 10 years and which I personally have used for more than five. With Mozilla, you CAN commit code that breaks, and a human is "on the hook" and has to deal with a human "sheriff on duty" until breakages are resolved.

With Aegis you CANNOT commit code that breaks! No change is ever written to the repository until it is automatically built by the Aegis system. You can SUBMIT your code for checkin, and it sits in a queue on the server and is automatically test-built. But it is never committed to the tree permanenetly until some human "integrator" comes around and reviews the code, verifies that it built, then integrates it into the tree.

So with Aegis you guarantee for all other developers that they can always check-out non-broken code. With Mozilla's system, there is a long list of "manual" checks and balances (please don't checkin on red! please don't checkout on red! please resolve breakages with the sheriff!) With Aegis these situations are prevented by the software itself. Furthermore Aegis provides for regression testing and peer review.

And, don't be intimidated by Aegis's apparent complexity. I am writing a set of wrapper scripts to make it behave 99.9% like CVS. I recommend anyone interested in this sort of "smoke screen" testing to take a look at Aegis. Aegis doesn't merely "recommend" a process - it enforces the process.


Posted: Sun Nov 03, 2002 8:13 pm
by WL
Just something like Aegis' checkin system is what we need. I guess my main point was that with all the coding, we want to minimize the administrative tasks as much as possible. Something like Aegis' model would be brilliant. Any other interesting models out there? I haven't been coding for long enough to know. Still some of the tools mozilla uses would be cool to use- lxr for browsing and searching the source online and bugzilla is a great bug-tracking system (although fairly obvious and proposed by many others).

p.s. I didn't know about this before- thanks!