Forum OpenACS Development: Re: OpenACS development history via Git

Collapse
Posted by Gustaf Neumann on
Malte wrote
Thanks a lot for this explanation. It basically seems to fulfill all my needs:
i have started using git in spring and i am vey happy with it. currently, i have 7 git repositories for different projects, everything develops neatly. Git reminds me on TeX/Latex: the simple commands do most what you need, for more complex situations there there are a lot of clever gadgets available; many of those i have not needed so far. For me the biggest asset is the ease to create branches and its "sane" behavior (no troubles with renaming, moving files etc.). Git makes a lot of sense for me even without having a shared repository in mind, simple to keep track of multiple version of software i have in use or development. git is as well quite fast.

Git can be used like cvs/svn, but it offers a huge array of ways to collaborate. This freedom might be the biggest problems of git. One needs more coordination and clear policies about naming branches, tags etc. within a project, since everybody can do whatever they want in their repositories. In reality, this seems to work quite well (see e.g. the linux kernel project).

For the openacs kernel i am not sure whether it is a good idea to leave the centralized development model. At least for packages, it is a great way to share stuff which is for some reason not in the central repository. Also for OpenACS companies, seeing every customer installation as a separate branch/repository helps to factor out commonalities and make maintenance easier.

Tom wrote

I haven't yet figured out exactly how to keep up with the cvs commits, this is part of the lack of documentation.
check out for the full cycle: http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html

Collapse
Posted by Tom Jackson on
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.

Collapse
Posted by Tom Jackson on
Tom wrote
I haven't yet figured out exactly how to keep up with the cvs commits, this is part of the lack of documentation.

check out for the full cycle: http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html

This looks great, thanks for the reference. One question is about the huge OpenACS cvsroot. A comment in the above suggests using rsync (for sourceforge) to copy everything in cvsroot. When I did my cvs-to-git it took about 12 hours and I was mostly concerned with placing stress on the OpenACS servers. Is there any possibility of making a similar service available, or is the stress not too bad? I assume that rsync is used so that things don't change under your feet. If there is any interest I could rsync to one of my well connected hosts and folks could rsync from there. Maybe there are better ways to do this, suggestions?