vlion: cut of the flammarion woodcut, colored (Default)
vlion ([personal profile] vlion) wrote in [site community profile] dw_dev 2012-05-01 01:50 am (UTC)

As I noted before, I work full-time as a version control support guy. I, am, in fact, an expert... or serve as one. Feel free to laugh. I don't quite believe it myself. Most of that is foxfirefey's fault for getting me into hg years ago.

I actively use github, bitbucket, and will dork with other systems from time to time, not to mention my daily job (supporting two mercurial installs for the company as well as misc. ClearCase work).

Github absolutely is the wave of F/OSS and that should not be discounted. That alone weights toward using it. Other considerations abide:

- git Windows support has always been awful for everyone I've dealt with (bar one chap who loves Git Extensions)

- git is a much sharper and two-edged tool. People gonna screw up. Let's not make that too easy.

- hg is what people know. This is a *big* deal, particularly when you are not a source control geek.

- hg gives its power out incrementally.

- bitbucket is distinctly a second-class site compared to github.

---

My thoughts on (1)

I do *not* believe there are technical reasons to choose git over hg over git aside from storage space is slightly better in git. Either will work, modulo fiddling and fussing.

And for (2); It's very nice seeing things simply THERE on a webapp page. I believe it does enhance existing devs and help provide a nice public face. There might be very good reasons not to use a shared hosting environment, but I can't think of any for an open source project.

(3) Github is the best right now, and IMO, it is likely to stay that way. This should be the last item perhaps in the decision chain, for reasons I give below..


---


Reviewing dw-free's repo, I note it's very SVN-looking.

I would suggest that DW devs think about using a branching sort of model. Right now it 'looks' as if patches are sent in, which does not leverage the power of hg as much as it might.

I am a big proponent of branchy development. Here's why. Say you are working away for a month on your su-weet patch. Patch is rocking, yo. You have squashed it and mq'd it and it is sitting there ready to be sent up. Night before you send it out, your hard drive dies. And you ain't got backups. You lost yo' work! Bad news. You go home and have a sad.

On the third hand, in a branchtastic model, you make your branch (aka fork on github basically), and you can send your commits up every night. Then, at the end, you can tell the project maintainer, "BRANCH READY MERGE IN". It's more robust. If you have a bad case of real life, people can see what's going on and what version of the code its tied to. Or it will survive machine failure. The flip side is that your history is Out There to get embarrassed by. Well... yeah. :-/


---

Deborah is right in that tools need to come second. First, what problems are there? Second, how do you solve them? Third, what tools support them? Fourth, what tools support the tools?


Post a comment in response:

If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org