On Wed, Mar 13, 2013 at 9:41 AM, Terry Reedy tjre...@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_t files on 3.3a0 (on Windows)
and they seemed to finish and be ok other than altering the environment.
Terry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
