Merge lp://qastaging/~inkscape.dev/inkscape/lp988601 into lp://qastaging/~inkscape.dev/inkscape/trunk

There are 30 conflicts encountered in the merge, I double checked just in case. Please fix and resubmit the merge request.

Odd set of conflicts, most of those are not files I ever worked on. This may represent lp988601 being out of sync with trunk by a couple of revisions. I have not had a chance to rebuild lp988601 locally since the last set of revisions were merged in from trunk.

That said:

Text conflict in src/extension/CMakeLists.txt
Contents conflict in src/extension/internal/emf-win32-inout.cpp
Contents conflict in src/extension/internal/emf-win32-print.cpp
Contents conflict in src/extension/internal/emf-win32-print.h

the win32 variants are not used in lp988601, it uses instead:

emf-inout
emf-print
wmf-inout
wmf-print
(all with .cpp and .h)

The conflict in CMakeLists.txt may be related to that.

The only other files in the list above which I know have been touched in lp988601 are
/src/style.cpp
/src/splivarot.cpp

David, you might have to rebase your patch. It looks like you caught a revert on the bad side.

On 29-Aug-2013 10:08, Martin Owens wrote:
> David, you might have to rebase your patch.

If you translate that into specific bzr operations I will try. I think
I know what you mean, but I was not the one who submitted the merge
patch
to put lp988601 changes into trunk.

> It looks like you caught
> a revert on the bad side.

Is that possibly related to the dialogscript messages issue that is
present in
lp988601 since Kris last merged things in from Trunk?

Thanks,

David Mathog
<email address hidden>
Manager, Sequence Analysis Facility, Biology Division, Caltech

On 2013-08-29 19:08 +0200, Martin Owens wrote:
>(…) It looks like you caught a revert on the bad side.

@Martin - could you explain that last sentence? (Who reverted what and how, and how should it have been done correctly?)

AFAICT most of the conflicts listed above seem to be about files touched in the lastest merge (rev 11473 - 11475). I don't really know what had happened there in detail, but that merge intially missed a couple if things (mostly stuff which had been renamed / moved in trunk), and no longer built with autotools-based build envs:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/lp988601/changes/11745>

Personally, I'm curious to learn how a branch like this is supposed to get merged into trunk without any conflicts at all if it removes existing files:

> Contents conflict in src/extension/internal/emf-win32-inout.cpp
> Contents conflict in src/extension/internal/emf-win32-print.cpp
> Contents conflict in src/extension/internal/emf-win32-print.h

Those three files had been removed quite early at the beginning when I started to maintain this branch for David:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/lp988601/revision/11676>

Anything I did wrong at that time (r11676), or possibly later when resolving conflicts with merges from trunk?

On 2013-08-29 19:45 +0200, David Mathog wrote:

> Is that possibly related to the dialogscript messages issue that is
> present in lp988601 since Kris last merged things in from Trunk?

Such warnings at launchtime are harmless - they occur if the installed 'share/keys/default.xml' references a not-existing verb (yes, the dialog and its verb have been removed, as has been the entry in the keyboard shortcuts file - both in trunk
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12437>
and in lp988601:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/lp988601/revision/11743#share/keys/default.xml>

Did you uninstall and reinstall inkscape lately (to clean up the shared resources)?

On 2013-08-29 19:53 +0200, su_v wrote:
> Did you uninstall and reinstall inkscape lately (to clean up the shared resources)?

Another location (besides $PREFIX/share/inkscape/keys/') to check for
outdated verbs used in keybindings is the location for user-controlled
custom keyboard shortcuts, usually in '$HOME/.config/inkscape/keys/' -
the new built-in keyboard shortcut editor stored any custom changes
there, too.

If I understand correctly, this is a merged merge (i.e. it contains many different patches), there's an element on danger with doing this as it's harder to go back to the original coder to ask for conflict resolution. The person who's collected the code together into the branch is basically responsible for making sure it doesn't conflict with trunk. Removing files shouldn't produce conflicts.

> It looks like you caught a revert on the bad side.

If you sync with trunk just after someone committed a bunch of stuff, and then try and merge after they reverted and then modified, you end up holding a garbage delta... but in this case, maybe that's not the problem.

All conflicts named "Conflict adding file" are not real conflicts. Other conflicts may show differences in the file, but are as far as I could see changes that were intended.

I have just pushed a new version of the branch which - at least locally - merges without conflicts into trunk:
<https://code.launchpad.net/~inkscape.dev/inkscape/emf-support>
The new branch compiles successfully on OS X 10.7.5, and 'make check' is ok too.

Since there are now four devs involved in getting David's native emf/wmf support into trunk, I'll withdraw from further maintenance of either branch - feel free to propose a merge of the new branch (or keep this one). The new branch is like this one owned by the dev team (i.e. any member of the team has full access).

@JazzyNico - do you know whether there is a way to "close" this merge request (other than 'deleting' it, with link at top right)? <https://code.launchpad.net/~inkscape.dev/inkscape/emf-support> has been merged already, so keeping this one open as 'Needs review' seems rather redundant… I failed to discover a way to set the status of this merge request to something like 'obsolete' or 'superseded'.

That should do it.

@~suv - Since the branch is no longer active and replaced with another branch, I'd use the "Reject" status. "Merged" doesn't seen appropriate because the branch (lp988601) is not merged and we can't link it to a revision number. "Superseded" would be very handy here indeed...