[This is very off-topic, so I'll make this my last post on this topic. Email me directly if you want more info.]
On Wed, 2007-02-07 at 04:01 -0800, Nicola Larosa (tekNico) wrote: > Malcolm Tredinnick wrote: > > But it's all "git" under the covers. I wrote up a brief description when > > I started using this a few months ago: > > http://www.pointy-stick.com/blog/topics/software/version%20control/ . > > (I know, I should have directly commented on that page, and I would > have, if there would have been a way to do so. ;-) ) > > "One of the talks I went to at OSCON was about using mq: patch queue > management on top of mercurial, a la quilt." > ... > "Inspired by this talk, I checked out stgit, since I tend to use > cogito as my personal version control system of choice these days for > various reasons." > > You don't say what those reasons are; presumably you were already > using git and cogito, so trying stgit was the most efficient path. I didn't really seek out "most efficient". It wasn't needed. I needed "sufficiently efficient", and since I was already using git and cogito, something on top of those had a low barrier to entry for me. > Nonetheless, I am interested in the reasons why you apparently did not > consider using Mercurial and mq, that seem to have the features you > need, and are mostly written in Python. Well, stgit is written in Python, if that is one of your selection criteria. It's not one of mine, though. On a much more practical level, there are so many version control systems available these days, that the decision ultimately comes down to "pick one or two that are in wide use in the area you work in and use them". I work on projects that use CVS, subversion and git, so they tend to be the version control systems I use for my personal work as well. Keeping the command sets for more tools inside my head and readily available is more work than my old brain can handle. Mercurial just isn't mainstream enough in the domains I work in for it to be something I need to worry about at the moment. > It's not that one always aspires to a wholly Pythonic world (well, not > when fully awake, at least ;-) ), but if the tools are Pythonic, it > should be easier hacking *on* them, instead of just with them, if and > when needed. There are assumptions in that paragraph that don't apply to my choices here: (a) I am not really that interested in hacking on version control systems unless there is some kind of show-stopper bug (unlikely with the systems I'm using since they are all in production-level use on very large projects.), (b) not being in Python is not a problem if I want to look at the code (maybe it would be if Python was the only language I understood and I didn't want to branch out. But git and cogito are in C and shell, for example; not exactly fringe languages and two languages I can use comfortably if I wanted to work on these systems). To be honest, (a) is the over-riding point here: I just don't care about the language it's in providing it's something I already have installed on my system (so Darcs is never going to get a look in, for example). And once you get to some level of experience, all languages are pretty much the same, so a sufficiently motivated (read "desperate") person could work on anything with the right mindset. Although Python code is pretty readable and easy to understand when you first approach it and is my language of choice for almost everything these days, it isn't that much of an advantage that I'm going to use it as an exclusion criterion for a tool I primarily want to use (rather than develop). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
