最近有项目需要多人在异地协同开发,用什么来做配置管理呢?
当然,分布式的版本控制系统是首选,目前比较流行的有两个,Git和Mercurial(hg),为了比较决策,在网上搜了下,在Windows下开发的话,觉得hg更方便点,尤其是有tortoiseHG,异地共享更简单,当然,是指针对人数不多的团队,不是太大的项目,没有考虑性能问题。否则,可能还是Git有优势,想想看Linus的作品,目前用来管理Linux Kernel的开发,自然就明白了。

当然,mercurial也不是不行,python的开发就是用mercurial在管理,具体谁更好就不讨论了,关键是对我而言,哪个更加好用,简便才是硬道理!

觉得最方便的就是在于TortoiseHG集成了WEB Server,这样,在同步的时候,只要简单地从右键菜单上启动web Server,就可以把repository 发布出来,的确够方便吧?

show 下图片:

Start HG Web Server

启动后是这样的:

当然,在启动前,你还可以把相关的参数配置一下,仔细研究下,里面的东西不少。


ps: 今天打开看了下,阅读量一夜之间就有了不少,谢谢大家的关注,想想应该补充下内容,以对得起大家的时间

如果,你的机器在防火墙后,或者是没有公共的域名,使用WEB Serve的方式就有些不方便。当然,有不少的免费域名可以通过3322.org或者花生壳申请账号,并通过客户端使用。配置工作稍微麻烦点,这里就不写了,有兴趣的朋友可以参考下其他网上的说明。

在这里要补充的是一个利用邮件来共享repository的途径。

还是看图说话,写个简要的梗概,具体的细节部分需要大家亲自试一下才能体会得到。
1. 配置好邮箱设置


2. 发送变更

注:邮件中也可以发送patch,只是用文件附在邮件内容中,需要手工再处理下,不推荐。
如果只是在交流沟通时用倒也方便,仅是看看,不实际合并时比较好。

3. 协作者从邮件附件中获得:


相对而言,Git在windows上的GUI就简陋了些,尤其是没有简便的web发布功能令它逊色好多---对我这个实用的懒人而言,呵呵。尽管我用Git比HG早:)
Git GUI
相对于这个GUI界面而言,个人觉得bash的命令行界面还更灵活些,在Linux平台下,一些插件也使工作更加轻松和有效率。

附图是MinGW下的Git Bash使用界面,包含有命令自动完成,帮助使用等,也还算比较方便。




附: 这是另外一个人的意见,英文的,就不翻译了。 

当然,他也有他的道理----兼听则明,自己根据实际需要选择合适的才是最重要的,毕竟,有助于轻松完成项目才是最重要的。

Git vs Mercurial - Why I chose git

Background and Our Needs

I first heard about distributed version control systems from Allan Odgaard on the TextMate blog. We’ve been working for about a year on Unison, which is a web application to develop online training. Our development has been so fast-paced at times we’ve been forced to push out releases more quickly than we could test them thoroughly. More than once we’ve needed to push out a less-than-stable feature for a high-profile client. We would later realize something wrong with the feature, but there was no way to go back.Branching and reverting changes in version control software is supposed to allow you to do these things, but both are so annoying in SVN that we never actually used either. We only kept a branch around when we wanted to make a release and continue development in the trunk. We would never have dared roll back any commits

Enter Distributed Version Control

Distributed Version Control promised to solve these problems for us. We would be able to branch as often as we liked, which would then allow us to keep branches around for longer without worrying about merging them later.

I first looked at git, then tried mercurial (hg) for awhile, then finally decided on git. I’m going to try to provide an unbiased review of some of their strengths and weaknesses.

Realize that both tools are good at merging, both have strong user communities, and they are very similar choices. I found good comparisons hard to come by.

Mercurial

Mercurial has several advantages over git.
Excellent Documentation: The hgbook helped me to understand the concepts
Cleaner Commands: The interface requires fewer options and flags
Intuitive Commands: The names they picked for reverting changes make more sense
Windows Support: They have a full windows client, although using it to make lots of branches would get crazy fast
It also has some disadvantages
“Named Branches” suck: They added this feature as an afterthought. The way everyone branches is by “cloning” a repository. So, if you want to work in a new branch, you have to make a brand new copy of everything. The implementation of named branches simply isn’t workable
Rewriting History is difficult: hg doesn’t have the features git does here

Git

Git has its own strengths
Branching is Supreme: This is a big one. Git lets you make new branches at any time, and lets you switch back and forth between them in one working copy.
Remote Branches: Git can send and receive changes from several different public repositories. This is useful if you need to publish more than one branch so others can download your changes.
Merging and Rewriting History: You can squash several commits together into one big commit when you merge, getting rid of the useless messages. You can easily pull a new version of the code you’re working on into your experimental branches.
Disadvantages
Slightly more confusing: There are more commands by default, and the reverting commands are hard to keep straight at first

The Wrapup

The interface to Mercurial is easier, and I like their mainstream approach, but git is simply far better with anything advanced. I don’t feel that Mercurial can handle making branches for each feature you are developing, and doesn’t do a good job of pushing/pulling changes from public repositories.

In the end, we picked Git. I’m going to revisit mercurial in another year and see if they’ve finished adding a few more necessary features. I wanted a DVCS in the first place so I could branch like crazy, and Mercurial really doesn’t support it well enough.

Posted in Environs.

其实,从DVCS本身来讲,我也倾向于Git,它的功能更加完善,可能有些命令不是那么直接,不太容易理解,也比较多。但考虑到一个众多志愿者参与的项目,像Linux Kernel这样的集市式的开发项目,Git作为一个目前来讲近乎理想的方案的确为Linux的快速发展起到了很大的作用,并且,它是Linus在长期的BitKeeper使用经验的基础上开发的,无论从需求把握的角度,还是从它的性能方面的设计考虑都有很多过人之处。

就我本人的经验而言,从开始做软件开发到现在,也有将近10个年头了,经历过几个公司,也参与过不少的大的项目,使用过几种商业的、或是开源的VCS,不少是被动接受的,后来自己选择,决策用什么,算是有些经验,但总体来讲,这些VCS是各有千秋,适用才是最好的。

从接触的先后顺序来说,依次使用过VSS、CVS、ClearCase、Perforce、SVN、Git,前段时间才听说HG,觉得不错,现在为了新的项目,临时学了下,总体来讲,一般在局域网环境中使用的话,我还是喜欢CVS,毕竟,这是个大家都熟悉的工具,简单易用,也不必再为了这个工具来专门花时间来培训团队人员,否则在使用过程造成的麻烦可能会带来些不必要的开销。 但在异地开发、或者是项目比较大,各部分难以齐头并进的时候,DVCS系统才是更好的选择,另外一种应该选用DVCS的情况是,当项目需要严格的对外发布版本控制时,选择DVCS可以让各小组内部先保证小范围的集成顺利进行,这样可以避免在用集中式版本控制系统时,在deadline前,出现大家同时提交,冲突不断,拼命加班的情形。

如果,团队成员学习能力都比较强,建议在局域网内开发时,也选择用Git这样的DVCS,毕竟,个人习惯不一样,每个人的开发速度也不同,Git强大的分支管理和历史记录回溯功能,可以为项目进展提供强大的灵活性,也肯定会提高整体的开发效率。

相信,以后的版本管理中,类似Git的工具将会成为主流,Git也会变得更加简便易用的。




Feedback

# re: Git Vs Mercurial hg? 异地协同开发,分布式SCM方案选择!  回复  更多评论   

2009-04-29 05:35 by yuz estetigi
thank you very good site...

# re: Git Vs Mercurial hg? 异地协同开发,分布式SCM方案选择!  回复  更多评论   

2009-04-29 05:36 by yuz estetigi
thank you very good site

# re: Git Vs Mercurial hg? 异地协同开发,分布式SCM方案选择!  回复  更多评论   

2009-05-06 07:31 by bwlee
有个朋友看了我的这篇笔记后,给我提了点意见,在这儿回复一下,顺便作点简单的说明:

他的第一个意见是,这东西写得不太清楚,比如HG跟Mercurial是什么关系没说清楚,我想,这个问题应该这样来看,博客是自我的笔记,大家可以互相参考下,能带来点思路的启发,但不是教科书,官网上这类东西很多。再说了,写博客也没稿费的,呵呵

第二个意思是方案的选择理由,以及相关的异地开发并不只是要解决这一个软件配置管理就够了,这个倒是有点道理,的确,软件配置管理只是一个基本的问题,还有需求管理,开发、团队间的交流讨论,成员工作量的考核等,都是影响项目成败的重要问题。 但这一展开就太大了,没准备写成一本书:-)。
不过既然提到了这些,顺便把我的想法和做法大概列一下,欢迎批评指正。

需求管理的工具很多,但工具之间必须配合好,才容易起到1+1>2的效果,所谓管理出效益,也是这个道理,简单的把人头堆积起来更是不能直接加速项目进程的,甚至可能起反效果。 比如ClearRequest和ClearCase之间就是个比较好的配合,但关键点是太贵了,这家伙是在大公司呆惯了,资源无限,从来不知道体谅下我等穷人的难处,呵呵。不过开源免费的东西也有,像Trac这个就是跟SVN结合得比较好的工具。但最终还是要有个中心的配置服务器才方便使用,我这个轻量级的方案(其实是超轻量级的,呵呵),要用这个的话,也得搞个服务器,弄上Apache+SVN+Trac,或者是用比较流行的Bugzilla,但我对这些都有点不太感冒,说实话,在我的理解中,这些对故障跟踪的系统用在需求管理上,总还是有点不自在,后期维护用才差不多。
我更倾向于功能点的划分,在提交时就是根据功能点来做,每个功能点提交一个变更集,其他的东西,可以在DVCS内部作分支来解决,也就是在每个人的master分支上作团队同步,个人工作如果习惯上需要频繁修改提交,可以在分支上进行,先自行合并到master上,然后再同步。
这个只允许按功能点提交变更的方法以前在用CVS时试过,效果还不错,强调写好每次的注释,严格按功能点来做,这样,我在后期用statCVS统计的时候,也能比较清晰地弄明白各成员的工作量,方便项目总结时提供相关图表给大家,而不是简单凭印象来评价团队的工作,造成团队部分成员的情绪问题。Mercurial HG和Git目前都没有这类的工具,是个缺憾,但应该很快就会有的,这两类工具的变更集和日志更完善,也支持外部插件,做个统计分析的工具成插件都可以。
至于团队间的交流也好办,大家约好时间,定下会议议程,开个网络视频会议就搞掂了,至于工具,NetMeeting, MSN,还有skype什么的一大堆,关键是如何用好,我倾向于会议主要讨论计划及通报进展,影响全体的技术问题在会上讨论下,否则,技术问题还是在成员间自由交流比较合适,至于,技术的共享和培训,在前期做下相关技术的培训,后期团队成员的项目总结上作正式的交流比较好,项目进行过程中还是不搞形式上太正式的技术研讨,因为容易流于形式,也不会有太深入的理解,除非是里程碑点出现了严重的偏差需要纠正,否则还是私下交流点实用的经验更合适。

# re: Git Vs Mercurial hg? 异地协同开发,分布式SCM方案选择!  回复  更多评论   

2009-11-24 19:10 by saç ekimi
very useful informations thanks for sharing.They are too neccessary for me. I bookmarked.

只有注册用户登录后才能发表评论。


网站导航:
 

posts - 44, comments - 43, trackbacks - 0, articles - 5

Copyright © 小李飞刀

涉足江湖,广交朋友
寻找有共同兴趣爱好者一起开创掌上移动应用!


欢迎光临!您是第 hit counter 位访客。