James Carlson wrote: > Shawn M Emery writes: > >>> There are ways to achieve it, now. Use of export/import works >>> gracefully, as does using the mq extension. >>> >>> >> The problem is not that are no known ways to work around these issues, >> the problem is that they are not being implemented in practice. >> > > Without _simple_ tools to do that, I doubt anyone will go to the > trouble. And it doesn't make sense to me to make new rules for people > to follow that aren't supported by the tools at hand. It just makes > the problem worse. > > At least for me, it's not worth the trouble to fight how the tool > works. It's more worthwhile to me to invest time learning how to work > *with* the tool than to pine for days and tools that never really > were. > > But that's just me. If you've got the time and energy to put together > a set of extensions that allow discrete per-file changesets within a > workspace to be managed easily, well, then, more power to you. > > One thing I find lacking is a definitive flowchart like set of commands needed to fix a bug or integrate a project both inside and outside SWAN. I know for ON work that I start with a clone of onnv and that there are internal mirrors. But I see that there is a repo called onnv-gate and onnv-clone. I know why we had that for teamware; which is the right one to clone from under mercurial? I think there is only onnv-gate outside SWAN, right?
Now that I have my own repo, then what? I presume that I need to run nightly, but is it best to run it in the repo, or have nightly clone the repo? I know that I don't have to check out files to edit them, but isn't hg going to have fits if I run nightly in the repo? There was mention a while back about an extension to cadmium that kept a list of files in a directory .cdm. What is the advantage of that? Should I get that extension and install it somewhere? In bitkeeper they say to update often to avoid conflicts. Same with bringovers and teamware. But with hg it seems that this can do something bad with the changesets, but I am nto sure what. Also, in teamware it seemed that you didn't want to check in a file until the end, but this doesn't seem to be true with hg. What is the standard edit-test-edit cycle? Sure things are different than when we used teamware. But I think there needs to a canonical list of commands needed to develop for OpenSolaris. Once we have that, then we can start improving on it with tools and extensions and things. Sorry if this wasn't the right thread or forum, but I just spent the day trying to puzzle this all out myself. Brian Utterback
