On Aug 6, 2012, at 6:26 PM, Greg Stein <[email protected]> wrote: > On Mon, Aug 6, 2012 at 6:07 PM, Dave Brondsema <[email protected]> wrote: >> On 8/6/12 5:57 PM, Peter Hartmann wrote: >> ... >>> I just did some work on the issue mentioned above (ticket #3883). Patch >>> needs testing, which I will probably do tomorrow. However, my ultimate >>> goal is to help Allura's making pypi release as soon as possible, to >>> ease overall deployment and thus make futher development easier. With >>> this in mind, if Hg begs for the same treatment as Git and SVN, I would >>> need to see to it next. I guess final decision on how to handle this >>> requires futher input from other devs as well? > > Seems that svn and git support should come built-in, since that fits > within our licensing regime. > > And yeah: if Hg support can be a "plugin" that users can install into > an Allura installation, then spinning that to another project (on SF, > I presume) would make sense. > >> Great to hear :) >> >> It seems pretty clear to me that the ForgeHg package needs the same >> treatment (making the core Allura package not depend on it), and even >> more so: to make it a separate GPL-licensed project/repo. The only >> other option I see is to write an Apache-licensed Mercurial library, but >> that seems unrealistic IMO. > > You never know what motivates people :-P ... entirely possible that > it'll scratch somebody's itch. I'm assuming that it would be possible, > and if/when somebody does it in the future, then we could support Hg > out of the box. Right?
Yep. Each "tool" is a separate pluggable discoverable python package. We could just bring it back into the main repo then. (The work Peter's doing on #3883 is to remove some unnecessary coupling between the core package and the scm tools - tests mostly iirc)
