On Mon, Jun 08, 2009 at 01:15:39PM -0400, maxime lemonnier wrote: > The more I read on git, the less I think it is well suited for EMC. Baazar > seems much cleaner. Sourceforge can host bzr (but, since EMC is packaged for > ubuntu, why not switch to launchpad?)
Sourceforge hosts git and bzr both. And, sourceforge is only one of the hosting options we are considering. > Here are the most convincing arguments, imo : To my eye, most of these are just statements of difference, not arguments in favor of bzr. Can you say why, for each (or some?) of these, why you think they are important arguments for the EMC developers and their current way of working? > >From : http://bazaar-vcs.org/BzrVsGit#Bazaar%20vs%20Git > * > * > > *The key differences between Bazaar's and Git's UI are: * > > - > > *Directories are branches. In Git they are branch containers where you > switch to different views. * My opinion is that git's way is better in this regard. If you have two branches with only a few files different, with git you can switch between them and only rebuild the changed files. People either love or hate the directories-are-branches scheme. I happen to think it's a misfeature and it's the primary reason I dislike bzr. People who like it will say it's the primary reason to pick bzr! > - *Empty directories cannot be versioned in Git. * I don't see this as important. Do you have a case in mind in EMC where we would depend on versioning empty directories? > - *Within a branch, changes directly made are emphasized over changes > from a merge. * I don't see this is an important argument (in fact I don't see how it's an argument at all) > *Revision objects are simple: r1, r2 etc. In git they are > SHA1s<http://git.or.cz/gitwiki/GitGlossary#object_name>which are > represented by 40 character long hexadecimal encoding. This is definitely one thing I like about bzr. If you mostly work from one repository, as I think we will (at least at first), it would be pretty workable. My understanding is that if a project becomes more decentralized, the usefulness wanes. > - *Git?s automatic merge and commit may create problems. * ?? > *Git has over 150 different commands. The UI between these commands is > not consistent, and there is no unified GNU --long option convention > support. * I agree the git command line user interface is a bit of a train wreck. But, the usual command-line operations are easy. The gui is good for doing unusual things. Our current practices are very basic and we have feedback from most of the current heavily-active developers who have not found any particular trouble with the basic operations they have tried. > - *Bazaar uses familiar commands known to Subversion and CVS users. Git > contains a whole new vocabulary: for example, commit into repository is > very > different in Git. * I don't think this is true. Instead of "cvs update -dP" you type "git pull". Instead of "cvs commit" you type "git commit -a" and then there is the extra step "git push" when you want to share your commits. For someone who is savvy enough to be contributing to a free software project, this is just not going to be a hurdle. Jeff has put together a page here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git that will help current CVS users get started with everyday tasks. > **Robust renaming* ** > > *Git prides itself on being a ?content manager? and deriving what got > renamed using heuristics. This mostly works, but breaks under certain merge > conditions. If you want your team or community to collaborate without fear > of breaking merges, Bazaar's robust renaming is essential as explained by > Mark Shuttleworth?s article > <http://www.markshuttleworth.com/archives/126>on this topic. I read this and did not see any comparison with git, except "Bzr and Git both handle this pretty well" and then it says how git is faster. The article also says that merge quality "benchmark[ing]" is "hugely subjective" but bzr is "fantastic". > *Familiar commands for Subversion and CVS users* ** See above. At the bottom of http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Development we are collecting a list of people and a quick for/against for a git switch. These are all the people who have ever checked in any code to EMC. We will surely not hear from all of them. We have a lot of "in favor" responses so far, mostly clustered around the top of the list (corresponding to recently-active and/or heavy contributors), and no "opposed" responses. I would hope any "opposed" response would be accompanied by an explanation ("user story") where the developer wanted to (or did) a certain thing in the course of development, and this thing is hard or impossible to do with git, and is easy (or at least possible) with another system. A story like that would really give the board a reason to stop and reconsider. Simple preferences (I think "update" is easier to remember than "pull") or arguments about esoterica like extremely uncommon merge situations are a lot less convincing. Again, thanks for your input, and if you want to elaborate on any of the points, especially if you can give a "user story" about how they are important for EMC in particular, please do. Chris ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
