Paul Armstrong writes: > Glen Wrote: > > Somewhere underneath the plans to get the rest of the Install code > > capable of being open sourced. > > This is why it's in it's own tree instead of part of onnv?
It just is. :-/ (I'm not sure that explaining this ancient history, some of which involves politics, or even the recent history of admin/install, is going to be helpful here.) > It's mostly just a case of using an SCM versus not. Being able to > do an update to the tree you're working on and mark collisions as it goes > (possibly even allowing you to fix them as it goes) instead of having to > generate a patch, download the latest tarball, untar into a new > workspace and then see if the patch applies cleanly are considerably > different. A simpler way to do this is to create your own independent SCM repository and then check that new tarball (or rather the files inside) into the repository on each update. The SCM merge tools should then work on any child workspaces you have. Agreed, though, that it's a pain, and it's something that needs to be fixed. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
