> I try to have a very pragmatic approach to tools. If something works, > I'll use it, until I find something that suits my needs better.
Yes, that's my approach, too. I also use git for other projects. > In the weblocks/hg case, we know that darcs did not work. Hg was > chosen. I gave hg a good try and I believe it doesn't work well. Here's > why: > > -- each branch is effectively a separate tree, which makes branching > artificially expensive. Also, once I clone a branch, I know of no > way to visualize where it split from weblocks-dev other than > tracking the last common changeset manually. > > -- you can't maintain small topic branches effectively, Recent work for hg (pbranch, localbranches, bookmarks) has offered new possibilities that are very similar to git branches. They have to evolve another little bit, but I think in the mid-term it won't be a problem to use these facilities. > -- as a result, weblocks development has split into multiple huge > forks, instead of tiny topic branches. These mix a lot of > functionality in them and are very difficult to pick apart. It took > me a long time to pick what I needed from Leslie's > modern-dispatching fork and it wasn't a happy experience, Yes, we could do better here. > -- trying to co-maintain large branches alongside -dev results either > in them diverging or in a gazillion of merge commits which makes > reading history difficult, The "rebase" extension that is part of hg 1.1 should help here, too. > -- last, but not least, I do not have a good visualization tool for hg > on a Mac and I haven't found an easy way to show just one changeset > diff in hg (git show does this). But that's probably just me being > stupid. hg diff -r tip:-2 > I disagree with both, I believe the newbie-unfriendliness of git is a > myth. See http://whygitisbetterthanx.com/#easy-to-learn for a comparison > of git and hg commands. I really don't see what is easier or more > difficult with either of them. Probably a matter of taste... > Possible differences speed are negligible and usually in favor of git. Not for me. I can definitely confirm git thrashing my disk more and taking longer for simple operations like diff and log. After "git gc", that is. > Also, I do not buy the story about "the overhead of switching". I do not > see where the overhead is. In fact, apart from learning how a new VCS > works (which takes all of 10 minutes for VCS out there) there is no > overhead to speak of. We could be switching VCS systems every week and > we wouldn't really notice. Well. Updating all the URLs, moving the whole shebang to Github and everyone else would have to convert their repos. It's a certain overhead that would surely take more than a few minutes. > However. I do not intend to convince anyone to switch to anything. To > put it in other words: may ketchup users live long and prosper, while us > mustard users are happy with our mustard. Whatever works for you. After > all, there is no harm in exchanging patches as patches, instead of that > all-fancy pull/fetch/push thing in every VCS out there. As for me, for > the time being I will *have* to keep working with git not because I like > it more, but simply because I am unable to do the same with Mercurial. We need to devise a better development model, that's definitely true. I will try to come up with something. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" 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/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
