Mark J. Nelson wrote:
>>
>> % 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.
>
SSHCLONE=ssh://onnv.sfbay.sun.com//export/onnv-clone
LOCALCLONE=/ws/onnv-clone
If I created my workspace from $LOCALCLONE,
>> % hg clone /ws/onnv-clone $HOME/work/myws
>> % hg clone /ws/onnv-clone/usr/closed $HOME/work/myws/usr/closed
>>
% hg pull $LOCALCLONE (works)
% hg pull $SSHCLONE
asks for my password, not passphrase, and doesn't work
AFTER you had already found the problem of the unnecessary proxy
for opensolaris.org in ~/.ssh/config, the DSA key was already in
place.
If you're saying that I can hg pull from both $LOCALCLONE and
$SSHCLONE, and it should work either way, I'm looking at a ws
right now (3-4 of 'em actually) where that's not true, for me.
> 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.
Have you seen the trust messages multiply? Like if there was one,
does it become two or three or more? Mine went from one to two.
If 2, 3, 20, 22 of them are no cause for concern, ok.
>
> 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.
I can give you a workspace. I don't know how much of a mess it
is, and can't remember how it got the way it is.
>
>> 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.
>
If you notice the # <op>_ws comments in my original email, I don't
think they're teamware-ish, nor hg-ish. My little world only has
5 commands, anything more is from the Evil One to lead us astray. :)
>> 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.
Yeah, ok. Excuse me for not understanding completely... because of
lack of handling for partial merges during putback/push this tool
isn't available? If I promise to be really careful, can I have it?
D.
