Ticket #3911 (closed defect: fixed)

Opened 3 months ago

Last modified 2 months ago

PATCH: adapt includesourcepartial plugin to the Trac 0.12multirepos branch

Reported by: gwk.rko@googlemail.com Assigned to: chrisheller
Priority: high Component: IncludeSourcePartialPlugin
Severity: blocker Keywords:
Cc: Trac Release: 0.11

Description

Please find attached my patch that makes the includesourcepartial plugin usable for the Trac 0.12multirepos branch.

Attachments

includesource-trac-multirepos.patch (1.7 kB) - added by gwk.rko@googlemail.com on 10/14/08 12:29:43.
adapt includesource plugin to Trac 0.12 multirepos branch

Change History

10/14/08 12:29:43 changed by gwk.rko@googlemail.com

  • attachment includesource-trac-multirepos.patch added.

adapt includesource plugin to Trac 0.12 multirepos branch

10/16/08 21:44:47 changed by chrisheller

  • status changed from new to closed.
  • resolution set to fixed.

Applied in changeset:4519.

Note that I only tested this patch to ensure that it still works properly in 0.11 as I don't have an 0.12multirepos environment to test against. I'm assuming that the submitter already checked that :-)

10/26/08 07:05:01 changed by martin_s

  • priority changed from normal to high.
  • status changed from closed to reopened.
  • resolution deleted.
  • severity changed from normal to blocker.

This patch introduces a heavy bug on my trac 0.11.1 installation. All URL schemes given in the example section stopped working because the 'trunk' is taken as a repository name!

So e.g. [[IncludeSource(trunk/proj/file.py)]] gives me an 'proj/file.py not found in revision 123' error.

Providing 'trunk/' twice fixes the problem partially: the source code is displayed but the link to the full source file is incorrect because of the second 'trunk/'.

Downgrading to the previous revision fixes the problem.

This patches completely break backwards compatibility (at least on my installation) and isn't needed for 0.11 anyway, so I suggest to remove it from the 0.11 branch and only have in the 0.12multirepos branch.

I also like to suggest to update the usage section to explain how to use the new multirepos syntax before applying such a patch.

10/26/08 22:23:59 changed by chrisheller

  • status changed from reopened to closed.
  • resolution set to fixed.

OK, I think that I must have run the tests in an environment that still had the old version of the macro installed, which explains why I didn't see any regressions.

After realizing that, I have now made the test for the multirepos code more explicit by looking for the new IRepositoryProvider interface in the multirepos patch. If this interface does not exist, then the original code runs.

@gwk: I have slightly modified your existing patch logic to now raise a TracError? if multirepos support is available and no repository is returned.

However, I'm still not 100% sure about the inner workings of the multirepos patch, so I don't know if this is the correct behavior. Is it possible to have the multirepos patch installed, but only be using one repository? If so, then what is the proper test to discover whether multiple repositories are being used?

10/26/08 22:38:19 changed by chrisheller

Nevermind the previous question. I took a closer look at the multirepos patch and see that the original line is the way to go. Restored in changeset:4590.

There is a comment in source:sandbox/multirepos/trac/versioncontrol/api.py that indicates that at some point the get_repositories method will return a default repository so this may need re-visiting in the future.

10/27/08 03:50:36 changed by gwk.rko@googlemail.com

Hey, just wanted to say I'm sorry I caused you quite some grief. I should have been more explicit when I posted, should have said that I created this code for the multirepos branch only and did not consider the case of running this same code in 0.11. I'm sorry.


Add/Change #3911 (PATCH: adapt includesourcepartial plugin to the Trac 0.12multirepos branch)




Change Properties
Action