I think it's mostly a technical reason. In particular, I don't think that there are any legal reasons why the respins are kept internally. The gatekeeping staff may correct me if that's the case.
In the days before Mercurial, in-repo branching wasn't really possible, so the way you'd branch was to clone the gate and putback changes to it, leaving it archived in a special directory. At the time of the switch to Mercurial, it didn't support in-repo branching particularly well (no named branches, for instance), so we just kept going the way we had before. Even after good support for named branches came into Mercurial, one of the key tools that ON developers used, the cadmium extension, didn't support them at all, and could in fact lead to very tangled repositories if used without extreme caution. So even if the gatekeepers were willing to switch to in-repo branching, it would have been dangerous to do so. That was fixed in build 134, so that should all work just fine, as long as all consumers are expected to be doing work on build 134 or newer. Adding in the respins for each build would be doable, though a bit tricky for existing builds. Mostly, a policy would just need to be written (branch names and comment structure, mostly). Note that extra-repo branching could also be done, and all those branches made available on hg.opensolaris.org in different repos, but that's a fair amount of work and not, IMHO, a huge benefit. The gatekeepers are on this list, and may be willing to entertain this notion. Danek _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
