David Marker wrote: > Mike Kupfer wrote: >> I'd like to get gpyfm installed well enough on my desktop that I can try >> using it instead of FileMerge, even for work in Teamware workspaces. (I >> expect it won't have Tooltalk support. That's fine; I'll cope.) >> >> So I see there's a copy of gpyfm and fm in usr/src/tools in the onnv-scm >> repo. Do I need to build usr/src/tools and install the resulting >> SUNWonbld? Do I need to do anything to make Python find the fm package? >> >> thanks, >> mike >> _______________________________________________ >> scm-migration-dev mailing list >> scm-migration-dev at opensolaris.org >> http://opensolaris.org/mailman/listinfo/scm-migration-dev >> > > Hi Mike, > > Sorry about such a late reply. > > Did you check out http://www.genunix.org/wiki/index.php/gpyfm-tutorial ? > I haven't seen any putbacks for gpyfm, so the tar.bz2 should be up to > date. gpyfm uses this technique to find the fm package: > sys.path.insert(1, '%s/../lib/python' % (os.path.dirname(sys.argv[0]))) > > So while gpyfm is intended to be installed as /opt/onbld/bin/gpyfm that > isn't required. It will look for its package in ../lib/python. > That means you can install gpyfm in ~/bin and have fm in ~/lib/python. > /opt/onbld is not hard coded or required. Its just a script, so you > don't even have to byte compile it to run it, python will do that for you. > > As far as teamware goes, it wouldn't be hard to write a front end for > that. The only file you should need to change is gpyfm.py itself. > I had intended originally that there could be gpyfm-hg, gpyfm-tw, and > even gpyfm-cvs. But I haven't had time (and I've already got two RFEs > when I do get time), and it wasn't deemed necessary to the SCM migration > project. I believe I left sufficient comments in gpyfm.py that it > shouldn't be too hard. > > As I recall, when there is a conflict with teamware, it adds an extra > delta. So if you had 1.27 and the gate/clone you pulled from has 1.27 as > well (because somebody else put back) then you should end up with a > 1.27.1. It probably gets a little more complex if you have several > deltas you have not collapsed. So in order to get parent/child/ancestor > you just need to "sccs print" the right deltas. That would have to be > handled in in __main__, where it currently expects to be given those > three files on the command line.
While I can't seem to currently find it (I know I've read it before...) McVoy had a paper regarding how TeamWare handles s-file merging that explained it in some detail (assuming it still matches reality), that should answer most questions regarding exactly how things look before during and after a TW resolve. > Then in quit you would need to copy the merged file (a temp file you > created) to the right place after 1st doing an "sccs edit". Not sure if > you would want to finish up with an "sccs delget" to check it in or not... > > But all in all it shouldn't be more than 20-30 lines of code change to > make a gpyfm-tw. Lots of os.popen() with your sccs commands. > > Another note, the code follows http://www.python.org/dev/peps/pep-0008/ > not cstyle. That is 4 spaces, not tabs. Most python follows this > convention, so I thought it better to adhere to this (it isn't C after > all, its python). For what it's worth, I agree, though most of the bits I've done have been following what Steve did initially (consistency being better than correctness and all that). -- Rich
