[Python-Dev] Looking for VCS usage scenarios

[Jesse Noller]

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