Re: How to fix roundup.org's customizing.txt

Hi John!

* John P. Rouillard <[email protected]> [20180908 02:07]:
> In message <[email protected]>,
> Joseph Myers writes:
> >On Fri, 7 Sep 2018, Thomas Arendsen Hein wrote:
> >> My suggestion here would be to to a 1.6 branch, branching off at
> >> the 1.6.0 tag that will lead to a 1.6.1 release at some point.
> 
> This is done and pushed using the direction in the previous email.

\o/

> The
> only issue I had was "hg show work" doesn't do anything. No errors or
> output. "hg help show" shows output for showconfig.

Oh, right ... show is an extension, too, and it was only recently
(Q2 2017) added, so you depending on your installation you may not
have it available.

Try adding "show =" to the [extensions] section of your ~/.hgrc

But you already found "hg sum" and additionally there is
"hg outgoing" (or short: "hg out") which will show you the
changesets that you have not yet pushed.

> >That's also my suggestion for when we want something based on the 1.6.0 
> >release plus fixes.
> >
> >I'd like to suggest that if we create such a branch, it should include my 
> >patch
> >
> >changeset:   5517:0cdf19b82354
> >user:        Joseph Myers <[email protected]>
> >date:        Mon Aug 20 00:50:16 2018 +0000
> >summary:     Fix issue2550994: breakage caused by configparser backports.
> >
> >as a fix for a Python 2 issue with one of the older Python 3 patches (by 
> >ESR last year) that is in 1.6.0 (so a regression in 1.6.0 relative to 
> >older releases).
> 
> I did:
> 
>   hg co maint-1.6
>   hg graft 0cdf19b82354
> 
> I get:
> 
>   merging CHANGES.txt
>   merge: warning: conflicts during merge
>   merging CHANGES.txt failed!
>   couldn't find merge tool ...
>   merging roundup/configuration.py
>   abort: unresolved conflicts, can't continue
>   (use hg resolve and hg graft --continue)

It seems you (or your distribution) haven't configured any merge
tools, I'll add some information about this at the end of this mail.

> I don't want the
> 
> +=======
> +2018-??-?? ?.?.0
> +
> +Features:
> +
> +- issue2550901: add search page to jinja2 template (Christof Meerwald)
> +- issue2550982: use PBKDF2 in Python's hashlib, if available (Python
> +  2.7.8+), to improve performance over bundled pure Python
> ...
> 
> changes.

For this special case here (in case of conflicts you want the local
file to win), you can use:

  hg graft --tool :merge-local 0cdf19b82354

("hg help merge-tools" shows all those internal merge tools)

> While I can CHANGES.txt so only Joseph's change is there, I
> am not sure how to set it up so that I don't create more issues when
> people try to merge changes from maint-1.6 to the trunk.

When not porting the things in CHANGES.txt, the merge is trivial and
automatic.

When adding the changes in maint-1.6 to CHANGES.txt, there will be
merge conflicts that need to be resolved. For grafting from default
into maint-1.6 you'll need an editor to do the changes. For the
merging maint-1.6 into default this can be fully automatic, when
using "hg merge --tool internal:local maint-1.6" (with newer
versions of Mercurial you can drop the "internal" and just use
"--tool :local")

Question is: Do we want the changes in maint-1.6 listed in
CHANGES.txt, even if that causes some additional work?

> I don't think this will be an issue if we always modify trunk and
> cherry pick them back to maint-1.6 branch, but before I check anything
> in I thought I would ask for guidance.

Worst case is that there are conflicts during the 3-way-merge that
need to be resolved.

> Also I think we need to merge:
> 
>   changeset:   5527:a7c3cd2edf51
>   user:        Ralf Schlatterbeck <...>
>   date:        Mon Sep 03 12:00:46 2018 +0200
>   files:       CHANGES.txt roundup/hyperdb.py
>   description:
>   No traceback for non-existent items in history
> 
> and I assume I will have a similar issue here as CHANGES.txt seems a
> likely place for conflicts.

See above, one way could be to skip the entries in CHANGES.txt, the
other would be to configure an appropriate merge tool (which is a
good idea anyway) and merge the lines that are wanted.

> I have run "hg update --clean" in my workspace so I think I have a
> clean area if my hg graft was the wrong way to do the merge.

Yes, "hg update --clean" (or short "hg up -C") throws away all
uncommitted changes/merges/grafts/... so you can start from scratch.

You can use the strip extension if you want to get rid of things
that already have been committed, but have not yet been pushed.



Regarding merge tools:

You can view your current configuration of merge tools with:
"hg showconfig merge-tools"

Your distribution may already have a mergetools.rc installed
somewhere. If it isn't active, you can use the following in your
~/.hgrc (or /etc/mercurial/hgrc) to activate it:

%include /path/to/mergetools.rc

The settings may not suit your preferences, feel free to copy and
edit it as you like. I have attached the merge-tools.rc we use at
Intevation for your convenience.

The available merge tool with the highest priority will be used.
In my example file I have used only negative priorities, so you can
include it and afterwards raise the priorities of certain merge
tools without editing the file by adding them to your ~/.hgrc (after
the %include if that isn't in /etc/mercurial/hgrc).

For example if you want kdiff3 to be used, but a fallback to vimdiff
if no X11 is available (e.g. via ssh login):

[merge-tools]
kdiff3.priority = 10
vimdiff.priority = 5


Please ask your questions, I'm available to help :)

Regards,
Thomas

-- 
Thomas Arendsen Hein <[email protected]> - OpenPGP key: 0x5BB3F5195816791A
https://blogs.intevation.de/thomas/         - https://intevation.de/~thomas/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

_______________________________________________
Roundup-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-devel

[merge-tools]

vim.priority = -1
vim.args = -f $local
vim.premerge = keep
vim.check = conflicts, changed

internal:merge.priority = -2

internal:prompt.priority = -3
internal:prompt.binary = true

gvim.priority = -4
gvim.args = -f $local
gvim.gui = True
gvim.premerge = keep
gvim.check = conflicts, changed

emacs.priority = -5
#emacs.args = -q --eval "(ediff-merge-with-ancestor \""$local"\" \""$other"\" \""$base"\" nil \""$output"\")"
emacs.args = -q --eval "(ediff-merge-with-ancestor \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$local)\" \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$other)\" \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$base)\" nil \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$output)\")"

emacsclient.priority = -6
emacsclient.args = -a "" -c --eval "(ediff-merge-with-ancestor \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$local)\" \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$other)\" \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$base)\" nil \"$(sed 's/\\/\\\\/g;s/"/\\"/g' <<<$output)\")"

gvimdiff.priority = -7
gvimdiff.gui = True
gvimdiff.args = -f -O $local $other $base
gvimdiff.check = changed

vimdiff.priority = -8
vimdiff.args = $local $other $base -c 'redraw | echomsg "hg merge conflict, type \":cq\" to abort vimdiff"'
vimdiff.check = changed

kdiff3.priority = -9
kdiff3.gui = True
kdiff3.args = --auto --L1 base --L2 local --L3 other $base $local $other -o $output

tkdiff.priority = -10
tkdiff.gui = True
tkdiff.args = $local $other -a $base -o $output

xxdiff.priority = -11
xxdiff.gui = True
xxdiff.args = --show-merged-pane --exit-with-merge-status --title1 local --title2 base --title3 other --merged-filename $output --merge $local $base $other