After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745781 - resolve not working
resolve not working
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: VC: Subversion
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2015-03-07 10:33 UTC by gnome
Modified: 2015-08-29 21:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description gnome 2015-03-07 10:33:29 UTC 
if you try to resolve a svn conflict as suggested by the dialog, meld hangs & you get a stack trace on console:

Traceback (most recent call last):

+ Trace 234796

  • File "/usr/lib/python2.7/site-packages/meld/meldwindow.py", line 299 in on_delete_event 
    response = self.try_remove_page(page, appquit=1)
  • File "/usr/lib/python2.7/site-packages/meld/meldwindow.py", line 567 in try_remove_page 
    response = page.on_delete_event(appquit)
  • File "/usr/lib/python2.7/site-packages/meld/filediff.py", line 908 in on_delete_event 
    response = self.check_save_modified()
  • File "/usr/lib/python2.7/site-packages/meld/filediff.py", line 903 in check_save_modified 
    parent.command('resolve', [conflict_file])
  • File "/usr/lib/python2.7/site-packages/meld/vcview.py", line 702 in command 
    command(self._command, files)
  • File "/usr/lib/python2.7/site-packages/meld/vc/_vc.py", line 177 in resolve 
    raise NotImplementedError() NotImplementedError


As far as I can see (I'm no python programmer) only git and bzr implement resolve. The commandline of svn to mark it as resolved would be

svn resolved FILE

so this is defined in resolved_command - but I don't see any of them use this definition as a generalized solution. I would say it should be similiar to the bzr one:

     def resolve(self, runner, files):
        runner(
            [self.CMD] + self.CMDARGS + ["resolved"] + files, [], refresh=True,
            working_dir=self.root)


Filed as bug in Mageia 5: https://bugs.mageia.org/show_bug.cgi?id=15420
Comment 1 Kai Willadsen 2015-04-10 21:33:11 UTC 
For me, the real problem here is that we shouldn't even be trying to call the resolve helper, since our subversion plugin doesn't support it. Fixing the subversion plugin would be nice, but since we don't have an actual maintainer for that plugin, it'll have to wait.

I've pushed a horrible fix for this, so conflict resolutions for subversion repos just won't prompt to resolve. The resolve action from the UI will still work... it's just the prompted resolve that won't happen.

Thanks for the bug report.
Comment 2 gnome 2015-04-11 11:55:10 UTC 
Maybe your are right in arguing what is a bug or a feature, so maybe we should call this a bug/feature.
But in mageia the suggested a fix for this behaviour:
https://bugs.mageia.org/show_bug.cgi?id=15420#c10

and even there is no maintainer for this, any maintainer of the git/mercurial repo-support can add a simple command for execution.
I think implementing this call is easier and more user friendly, than to work around this.
And please face it, svn and cvs are still alive - not every project has migrated and wants to migrate to distributed version controls.

So please don't deactivate features (that are really helpful) only because two lines of code has to be changed in a unmaintained package.
Comment 3 Kai Willadsen 2015-08-29 21:04:29 UTC 
This has been fixed with the version control subsystem rewrite in 3.15.