[Python-Dev] Looking for VCS usage scenarios (original) (raw)

Jesse Noller jnoller at gmail.com
Mon Nov 3 19:45:43 CET 2008

On Mon, Nov 3, 2008 at 1:05 PM, Brett Cannon <brett at python.org> wrote:

On Mon, Nov 3, 2008 at 09:58, C. Titus Brown <ctb at msu.edu> wrote:

-> Sticking with a dvcs implemented in Python makes the best sense, -> especially when you consider the plugin architecture. When we -> selected a new tracker, we didn't make implementation in Python a -> requirement, but instead a high hurdle. Meaning, if a tracker wasn't -> written in Python it had to be way better than those written in Python.

I worry about the idea of hacking in any way, shape or form, on the version control system used to maintain the Python source code. I place VCSes at the compiler- or OS-level of the toolchain, because you have the option of fundamentally screwing up the entire project by playing with them. So from that perspective it's better to keep it out of Python to remove the temptation to hack :) I don't expect us to hack on the VCS itself. I am thinking more like plug-ins commit hooks, etc.; the infrastructure around the VCS. -> As for dvcs, I think git would have to show overwhelming advantage -> over bzr or hg to be considered. I personally have found git very, very powerful and good, albeit difficult to learn You can say that again. And that is a worry to me. Python gets patches from people of all skill levels where ease of use for the VCS needs to be considered. The Linux kernel probably doesn't get as many patches from newbies as the barrier of entry is higher to contribute. I have yet to have met anyone who thinks git is great while having used another DVCS as extensively (and I mean I have never found someone who has used two DVCSs extensively). . It is guaranteed to scale (unless Python gets to be significantly bigger and more active than Linux, at any rate) and it has a large, very technically capable, and supported user community already. I think any of the DVCSs will scale. But I will be taking some performance numbers so scalability will be taken into consideration. I think there are reasons why git should be at least strongly considered. Well, we will see, but as of right now my use of git has left a nasty taste in my mouth that will take a lot of proverbial mouthwash to get rid of and allow it to be considered in this PEP.

I don't see how git can be considered given poor windows support - compilation on OS/X can be a bear too.

And I echo the need/want to be able to customize the workflow and integration with the tracker/etc with something a bit more flexible. The bzr plugin system is nice.

Also the ability to completely nuke the local-work-copies commit history ("cleaning it up") worries me, but I'm also paranoid.

-jesse

More information about the Python-Dev mailing list