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.
