As Onno Kortmann wrote: > I discussed the last developments with Thomas and I was using git > specifically because some of you had problems with me having commit > access.
Well, it would have made sense to fix the commit access problems then... > That said, and to answer the question about git's advantages: git > easily supports multiple branches within one repository, ... This is about true for *any* VCS I know of, including (again) the venerable CVS. The major cost of a branch is to eventually merge the branch back once the time has come. This is where I'd see the real problem about branching. > People who clone the repo get everything and can look at the > states of the various branches. For this, it shouldn't even be required to clone a repository, just checking out the branch (instead of trunk or HEAD) would suffice. > Git surely does not replace communication on the ML here, but I feel > it gives people a great incentive to contribute if a main dev would > give commit access or, at least, pull the changes from some other > repository (such as mine on github) into the main one. One real disadvantage I'm seeing with the "offline" git version is that there are no commit messages relayed through the mailing list, so nobody except the core developers do know what's going on there. > This of course would create a fork but I think this is always the > case if you want to support a stable and a development version. And > that, I think, would be very good idea now. I don't see a stable version so far. There hasn't been an official simulavrxx release for more than 4 years now (only one that is named "simulavrxx_klaus_00.tar.bz2" last year). But of course, if the things you are working on really aren't stable so far, then the costs of a branch would be justified -- but that only makes sense if there is a kind of schedule (not necessary by date, but at least by some kind of TODO list or so to walk down) for eventually merging the new functionality back into the mainline code. Otherwise, it will still be a fork. And no, please don't expect anyone else to do the merge, the only one who is able to merge is/are the developer(s) who is/are actively working on the branch. > I think even you decide [...] There is no "you" whom you could address here. This "you", that are: Onno, Thomas, Michael, maybe Joel. Klaus said Good-Bye many months ago, and has not been seen ever since. I don't even know whether he's still following this mailinglist, maybe. Eric and me are only here to take care of "household" things, to offload boring project maintenance tasks from the actual developers. > It would be nice if the project would only have a single point where > the latest source code is, and this should be the savannah > repository. So there appears to be general consensus about this. > ..., but git at least helps as much as it can in > doing merges. Again, that's essentially true about every VCS I've seen, though arguably, it's not the brightest side about CVS. But then, if it comes to a truckload of conflicts, you're out in the rain for a manual merge with any VCS. > Also, it supports local development, which is very important if a > dev does not have commit access to the central repository. As there are only very few active developers anyway, they should really go with master repository access instead. I think local development does more of a mess then than it would be helpful. (old simulavr-0.1 codebase) > If wished, I volunteer to import the old code base into a git > repository. It boils down to a call of 'git cvs-import' with the > correct parameter set. I'd like to first see some consensus about the VCS to use. Savannah offers CVS, SVN, and git, so that would be the possible candidates. Once this decision has been made, plans should be crafted how to migrate the old repository (in case the new decision will not be CVS), and migrate the stuff from Onno's offloaded git repository back. Again, this is just a proposal, it's you (the active developers) who have to decide about the path to take. > As its code base is completely independent of the simulavrxx stuff, > it is probably a good idea to have an own separate git repository > for it. Without any simulavrxx stuff. It hope savannah supports > that. It depends on how git repositories are organized. For CVS or SVN, savannah only offers a single repository per project (plus an additional CVS repository for the project web pages). So far, both sub-projects have been organized as two top-level directories within that single repository, so the only shared information between both is the repository infrastructure itself which is quite opaque to the developers (as it is handled by the Savane web interface and/or the Savannah admins only). The only consequence I'm seeing out of this is there is only one possible commit mailinglist, and with SVN, there will be a single revision number space for both. (Don't know about git here, CVS was/is different as each individual file carries its own revision number space.) If simulavrxx continues to develop with at least the pace it does by now, I don't see any need to ever commit anything against to the old simulavr codebase though, so its presence in the tree would be mostly to keep the VCS history of that old project intact. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
