On Wed, Mar 13, 2013 at 9:41 AM, Terry Reedy <tjreedy@udel.edu> wrote:

Bottom line: I decided to restart from scratch. I am still not sure if the glitch was hg, disk 1, disk 2, or Windows, or some combination.

After making and posting a patch to the tracker today, I tried to annotate a file and got an error something like 'cannot find revision -1'. I then noticed that there was no dag in the workbench dag window, as if there were no revisions. When I looked in .hg/store, the big file seemed to be missing.

Note that with the share extension, the "big file" (which I assume is the store/ directory) only exists in the "main" clone. In the shared clones you'll find an .hg/sharedpath file that contains the path to the original .hg/ that contains the store/ dir with all the changesets.

So I wiped, defragmented and compacted, and reloaded TortoiseHg. Tomorrow I will re-clone and share the repository. Since this is the second time I have re-cloned from python.org, I will follow the advice I read somewhere to make a _backup clone that I leave alone until I need it, so I only have to pull from now until then when I do.

Good idea :)

...

On 3/12/2013 7:34 PM, Ezio Melotti wrote: I wonder if TortoiseHg is doing something wrong here. Maybe you could try from cmd too.

Workbench has a 'command' window for typing hg commands which it should pass as is to Windows much as Command Prompt does. I tried some of the things you suggested there.

...

Around the time you pushed on 2.7 I also pushed something, so that might have created some conflict.

I do not remember seeing that.

I pushed on 3.3/default about half an hour after you pushed on 2.7, so that might have caused a push race, if during that time you were doing the merges and eventually tried to push after me without having pulled/updated in the meanwhile. The problem you described doesn't seem to be related to push races though.

...

How does your .bat look like?

pull -u to cpython + update of each of the three shares, much like written in the devguide.

It's better to avoid using "hg pull -u", because if there's nothing to pull the "update" won't be executed. Here it shouldn't be a big problem, but you could break it if you manually pull something in one of the shared clones, and then run the .bat. Unless you also have an explicit "hg up" in the clone where you do "hg pull -u", that clone won't be updated by the script.

...

That's possible. From "hg help graft": If a graft merge results in conflicts, the graft process is interrupted so that the current merge can be manually resolved. Once all conflicts are addressed, the graft process can be continued with the -c/--continue option.

When merge produces a conflict, a window appears offering options including using kdiff3 to resolve. When I tried the graft, the message in the command window was just 'aborted', and I do not remember getting the resolve window.

What version of HG are you using?

...

When I graft/merge and there are conflicts I use kdiff3, and it takes just a few seconds to solve the conflicts usually (for Misc/NEWS is ctrl+2, ctrl+3, ctrl+s, alt+f4, that roughly translates too "include both the conflicting news, save and quit).

Since I have perhaps never gotten that sequence right, that info will be helpful.

Glad to help, however I got it the other way around. The 1st pane is the parent and you can just ignore it; the 2nd pane is the local copy and the 3rd pane is the one from the previous branch that you are merging. The bottom pane will be the resulting file. For Misc/NEWS (the file that usually conflicts), you want the newest NEWS entry first, so you do ctrl+3 to get the one you just added, and ctrl+2 to get the one that was there already. Note that for other files you usually want to get only one of the versions, usually the one you have in the 3rd pane, so that sequence only applies to Misc/NEWS. Another tip is to use ctrl+q instead of alt+f4.

...

If you do it from cmd/file manager hg should see it as missing ('!' in "hg status") and you can use "hg revert Misc/NEWS" to restore it.

This.

Thanks for trying to help. I will let you know if there are any more problems after the re-clone.

Sure, and if you find part of the devguide that are not clear let me know (I also just uploaded a new patch to http://bugs.python.org/issue14468 to add a few new Mercurial FAQs to the devguide). Best Regards, Ezio Melotti

I still need to comment on the tcl/tk.dll and tkinter situation, but will just mention now that I ran the four test_txxxx files on 3.3a0 (on Windows) and they seemed to finish and be ok other than altering the environment.

Terry