Good comments. I would tend to agree that OpenACS should not ditch the centralized development model, but what exactly that means would be important to clear up. Obviously the kernel development ends up with releases, so in the end there are the same decision-making processes going on. This is critical for any project, and OpenACS has such a structure already. The point of using git would be to allow developers at least two thing: first, to commit (and thus comment and protect) their work as they go along, and second, to more easily keep up with the central development. Right now, sharing code means committing directly to the HEAD, then pulling stuff back in, but that could easily mess up what you are doing. Overall, it looks like git makes the flow of code, up, down, across much easier, which in the end will probably have the effect of encouraging more sharing, experimentation and testing. At the moment it is impractical to check out a new feature without making a new checkout of everything in some scratch directory.
But this is still a new tool, it will take lots of interest and testing for the community to get comfortable with it.
I also looked at the suggested Bazaar. Apparently this is limited to around 10k files, which is probably too low for OpenACS. I haven't done a count, but there were over 200k objects in my conversion.
The author of the articles was also somewhat confused about Git. He thinks that Git should support renaming files, even though this is completely unnecessary in Git. Git tracks content, and even sub-content. If you move a file somewhere else, or have two copies of a gif with different names (or maybe some empty placeholder files), these are considered the same content, there is only one copy, and only the pointers change. You can also track a function which moves from on file to another file.
Personally, this is exactly how I develop. I might use a testing file to develop a function, then move it into the correct file days or months later, long after I have forgotten all the development issues and problems. With svn, I leave the test file untracked and uncommitted.
I also often split code into separate files if they get too long and contain multiple namespaces. You shouldn't be thinking of this stuff in advance of the need to do it, so it would be a big help to capture this development history automatically.
Gustaf, I'm going to read the article about cvs-to-git-and-back. Hopefully you can share your typical workflow for using git with OpenACS, or other projects.
