Mark J. Nelson wrote: > I fixed the address for gatekeeper, and added the SCM team, which was > really more appropriate to start with. (Gatekeeper, sorry for the wide > distro.) > > We (the SCM team) are happy to help (before/during the fact) and/or > investigate (after the fact), but we need a ton more information than > what you've sent us. Repository pointers, history, steps to reproduce, > snapshots of purportedly hosed repositories, etc. > > Anyway, some responses inline below. > > --Mark > > > Dina wrote: > >> (gatekeeper alias: this is the summary for an ongoing thread >> where I had some problems trying to hg push ... besides the ssh >> problem from earlier where I had an unnecessary couple lines in >> my $HOME/.ssh/config that read: >> Host *.opensolaris.org >> ProxyCommand /usr/lib/ssh/ssh-socks5-proxy-connect -h >> 192.18.43.19 %h %p >> >> I'm stating the obvious I'm sure, so this is meant as a perspective >> on how some of us [me] needed to bumble along until we got it right. >> And I do have a request for clarification on how to set up for >> command-line, non-GUI merge conflict resolver ... and the right >> things to put in .hgrc. ) >> > > hgsetup should get your .hgrc correct. > > We have not (yet) provided a cli for conflict resolution, integration of > David Powell's "hgr" script stalled out a while back. (Long enough ago > that I need to dig through e-mail to see what the blocking points were.) > > There is support (of some fashion) for use of filemerge, meld, emacs, or > vim for 3-way merging. > > >> This is what worked ... yes, I had to create a new workspace >> to get this done. There are way too many steps here, and I >> found I had to reparent twice. I don't know if that's real >> or superstition right now. >> > > If you're claiming that a workspace could not be salvaged, please > preserve it and send us a pointer, along with (if possible) the steps it > took to get it into that state. Until then, I'm somewhat skeptical, > especially if you were only ever parented to either the gate or the > clone, which are synchronized repositories. > > >> # create_ws() >> >> % echo $GATE >> ssh://onhg at onnv.sfbay.sun.com//export/onnv-gate >> % echo $CLONE >> /ws/onnv-clone >> in my setup the clone is local >> the gate is ssh-remote, the local >> and ssh equivalents are not >> interchangeable, and instructions >> out there are ssh-centric >> > > They are interchangeable. > > Please be explicit when you claim otherwise, if you want us to spend any > effort figuring out why you're seeing a difference. > > >> % hg clone /ws/onnv-clone $HOME/work/myws >> % hg clone /ws/onnv-clone/usr/closed $HOME/work/myws/usr/closed >> >> >> # modify_ws() >> >> % vi ... >> <copied over my one line change from hosed workspace> >> % hg commit >> <typed in my CR id and description> >> >> >> # putback_ws() >> >> % hg reparent $GATE <-- following MJN instructions >> % hg pbchk which I think can be omitted for >> <type passphrase> same below >> % hg push (failed) >> >> >> # sync_ws() >> >> % hg pull $CLONE <-- does this reparent to clone? >> > > No, it does not. > > >> % hg merge if pull is a no-op, go straight >> % hg commit to reparent/push below >> % hg recommit >> <type passphrase> >> >> >> # putback_ws() >> >> % hg reparent $GATE <-- this seems necessary again >> % hg pbchk >> <type passphrase> >> % hg push >> <type passphrase, then it worked> >> >> # destroy_ws() >> .... >> >> I think what would've helped me is to change slightly the >> MJN instructions, so that it doesn't list: >> hg reparent $GATE >> and THEN explain how to deal with pulling from clone and merge >> and all that. Just skip the first reparent, do all your merges >> and stuff before reparent/push. >> > > Looks like this is probably leftover from writing the iterative part of > those instructions, but it's certainly harmless. > > >> Once I had reparent'ed to $GATE, then things don't go very well >> if I had to go back and deal with the $CLONE again. I think >> I tried to reparent $CLONE and I ended up with the 2 "Not >> trusting file..." messages plus some complaint about no default >> repository. When I tried to pull from the clone again, then >> the workspace got hosed. >> > > The trust messages are a red herring. They are harmless and can be > ignored, per the information in > http://www.opensolaris.org/os/community/on/flag-days/pages/2008080405/ > and in the hgrc(5) manpage. > > If you have no default repository, then you have either gotten your > parent (default) path wrong in your own .hgrc, or you're trying to > perform an operation on a repository that is not owned by you. > > Unless you can provide more details, including history and repository > access, and a definition of "hosed," we can't help. > > >> The instructions are correct, but not ideally laid out, IMVHO. >> > > We can't really write a cookbook that's going to make folks happy and > productive. Mercurial is a substantively different tool than teamware, > and attempts to translate commands/procedures step for step are doomed > to unnecessary complexity and confusion. > > Once you get your head around how Mercurial tracks and manages change, > the heads/branches/merges/commits make much more sense. As long as > you're trying to think of them as direct analogues to Teamware commands, > they're not going to behave as you expect. > > >> What would also help me is to have the command-line "resolve" >> from Teamware working in the hg environment. I prefer it over >> the GUI, which doesn't work in my home setup. >> > > This is a valid request, so I went and tracked it down. It's covered by > > http://bugs.grommit.com/show_bug.cgi?id=309 > > ...and the primary obstacle was the lack of handling for partial merges. > _______________________________________________ > scm-migration-dev mailing list > scm-migration-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/scm-migration-dev > Hi Dina,
Looks like you've had quite a party. I'm just a user myself here but wanted to share some pointers with you that I hope will help in your quest. Firstly: have you seen the Teamware to Mecurial Guide in wiki: <http://braindump.uk/wiki/index.php/Teamware_to_Mercurial> I see 'hgr' mentioned above, I was not aware of that tool. But am aware of another called hg-merge that works rather like resolve. It was originally posted to the SCM alias by John Zolnowsky at sun.com. I updated it to include 'filemerge' sub command as per teamware resolve. The script can be found at http://braindump.uk/wiki/index.php/hg-merge_script Regards, Stacey
