It will not be really useful for end users, but we would have a default to assign.

Comments

sdboyer’s picture

sdboyer commented

ehh...i'm still against it. if it were something we were expecting end-users to fix, i would agree. but i would prefer that we fail loud and large, because i don't think this it actually is an end user-facing issue.

if we add the logic to VersioncontrolBackend that we discussed yesterday, then the primary responsibility for specifying the default plugin rests on the backend implementation, not on the end-user. given that developers are the audience there, it's better that we have a hard failure (watchdog + exception thrown) than a soft failure (defaulting to a non-functional plugin), as failing to specify a default reposync plugin means that your backend really hasn't yet fully conformed to the interface.

marvil07’s picture

marvil07 commented
Title: Provide a simple reposync plugin » Implement a reposync plugin for the test backend

Changing target then.

sdboyer’s picture

sdboyer commented
Title: Implement a reposync plugin for the test backend » Provide a simple reposync plugin
Status: Active » Closed (won't fix)

discussed with marvil07, he agrees, so marking won't fix

marvil07’s picture

marvil07 commented
Title: Provide a simple reposync plugin » Implement a reposync plugin for the test backend
Status: Closed (won't fix) » Active

xpost here I think, we still want one reposync plugin to use on tests.

sdboyer’s picture

sdboyer commented
Issue tags: +vc-next

this is an important part of our test suite in terms of being architecturally complete, but we really don't NEED it to launch.