Forum OpenACS Development: Re: OpenACS development history via Git
1) I can use OpenACS Core as the main directory
2) I can use additional packages easily as they come by
3) I can create my own "cognovis" distribution which is easy to merge back to OpenACS (at the moment it is a little bit of a pain to merge between subversion and CVS, but it works)
4) I can provide certain code not officially as a package in OpenACS, but as something that I "control" on our servers. Very useful for packages that mainly I use and others might be interested to test, but should not be officially in OpenACS yet
5) I could use code developed by someone I trust who does not want to keep his code completely in OpenACS CVS
6) In the EU project I am coordinating, each partner could have their own repository for their software (which runs on different platforms) at their office and we could merge it once they punch a hole through their firewall 😊.
What I am struggling at the moment most with subversion is changes made to client installations. I usually use cognovis-core as the subversion checkout (pretty much a mix of HEAD and 5.3) on which to base the client code. Then I make a change at the client. It works in the client, I need to merge it back to cognovis-core, then I need to commit it to all clients and then I need to commit it back to OpenACS. Even with automated scripts it is a painful experience. Is this merging going to be easier in Git? I assume I could just copy the Git repository for cognovis-core and use it in the client's place and if code works, merge it back either to OpenACS directly or just to cognovis-core (e.g. if it is a change which needs a TIP).
My assumption is that my scenario is not so different from any other's OpenACS company, but correct me if I'm wrong. And note that I am not thinking about changing our Tipped decision to go with subversion, but trying to figure out what best to use for our (cognovis) scenario, hoping Tom will find a way to merge back to CVS or SVN for that matter 😊.
My typical method of development with OpenACS is to download the most current stable version and then develop on that. But I seldom make any core changes. The problem for me is not pushing changes back, but merging in new updates from OpenACS, but git or svn may not make things any better because this isn't just source code, but also datamodel and data. And there is the potential for lots of one-off edits to local files that you don't normally see in code development.
Pushing and pulling into a production environment probably shouldn't extend to any shared repository, this is the point of git: everyone shares what they want and pulls from these shares what they want (into their own repository). At some point, an official version can come out, but if your specialized code isn't in the official version, it doesn't mean you are cut off. So if you develop a feature which only you find useful, maybe it stays in your local branch. Then if someone else picks it up, maybe generalizes it, it might work its way up into the main branch. If the point is to maintain a monolithic repository, there is no need to move to git, it isn't really directed at shared repositories.
So what you might do as a developer with multiple clients is to maintain a development repository with branches for each client, or a private repository for each client, but the private repositories would still reference your local repository, which would eventually reference the openacs official version/branch/tag.
As far as merging stuff from git back to cvs, I don't know if that is possible. What I was interested in doing is pulling down new cvs commits. I have heard that developers are pulling from svn, merging and then pushing back into svn, so maybe you can do the same with cvs.
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
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.
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?
