Questions about contributing
ben at benrhughes.com
Thu Sep 8 07:40:00 CDT 2011
AFAICS there is no more than 30 places.
Yep, my grep was a bit loose :)
As you describe it it would be an unnecessary abstraction and extra
complexity and more verbose code without any benefit. I doubt a patch for
that would be accepted.
Admittedly I'm new to python, but I have a lot of experience in other
languages. I don't consider moving a commonly used string into a constant an
unnecessary abstraction: I'd generally call it best practice. Not trying to
start an argument here: your codebase; your rules. I'm just trying to
understand the objection.
A repo made by a Mercurial hacked as you describe it would no longer be a
Mercurial repository. One of Mercurials core values is that the repository
format only change in backward compatible ways.
I disagree. So long as the variable was set to ".hg" it would be perfectly
I'm not talking about any fundamental change here: just moving a string into
a variable. It's only dangerous to backwards comparability if someone
chooses to change the variable in their own build and then tries to use it
on a "mainstream" hg repository - which is true for any custom change to the
codebase. Surely this is an inherent risk in any open source project?
Note that Mercurial is GPLv2+. If you ever distribute your application it
would have to be under a compatible license. That should however not be a
problem if it is for internal use within your own legal entity only.
Unless I misunderstand the GPL (which is always a possiblity :)), calling a
GPL'd exe places no requirements on the calling app. Of course we would have
to make and changes we made to the Hg source publicly available. Please let
me know if you think I've got the wrong end of that stick.
Thanks for taking the time to talk this through.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel