On Wed, Jan 19, 2011 at 4:13 PM, Barry Haddow <[email protected]> wrote:
> > > For me, the ability to make commits on a standalone network is a big > reason > > to move to git. > > > > Hi Lane > > Do you mean that you can 'commit' without connecting to the repository? I > can > see the advantage of this if you want to work in private, although the > (dis)advantage is that it acts as a drag on people integrating their code > into trunk. We have enough trouble getting people to integrate their code > as > it is. > Yes, it does mean that you can commit without connecting to the central repository. This means that if you have your laptop, and you're coding on a plane, you can commit changes to your local copy of the repository. Likewise if you're coding (like me) in a standalone network that doesn't have a connection to the broader internet. In both of these cases, when you're done working offline, you can push the changes that you committed locally back up to the central repository. > Are there any other advantages? I can't see this as enough of a reason to > switch - learn a whole new set of commands, rewrite tutorials, deal with > the > ensuing mailing list queries etc. I've heard that merging is better in git, > but I manage fine with svn merge. > Adam can probably speak to the advantages of git much better than I can. I know where you're coming from, though. I was skeptical too of the advantages over merging in svn. Having seen the change in another project, though, I am convinced. In svn, you branch when you have have to. You'll do it rarely, maybe a couple of times a year, and then (grudgingly) you'll finally get around to merging your changes back into trunk. Or not, and the changes will forever stay hidden in your branch. In git, you branch all the time. You don't have to, but it's strongly encouraged. When you start work for the day using git, you'll probably start a new local branch. At the end of the day, you'll probably merge those changes. Branching and merging are common operations. These local operations effect only you, but the frequent use of branching and merging has the effect of greasing the mental skids when it comes to merging into the central repository. The overall effect that I've seen is that new code tends to be merged into the central trunk more frequently, and branches tend to be brought up-to-date with trunk with ease. This last point is enabled by a git command called rebase. Let's say you make a branch, do some work, and in the meantime a bunch of other changes get checked in to trunk. Rebase is a very slick way of getting the changes from trunk into your branch. Can you accomplish the same task using merge in svn? Yes. Is it as easy? No. Another issue is file renaming. In svn, when you rename a file svn treats this as if you had deleted the old file and then created a new file. The revision history of the new file only goes back as far as the rename. Git keeps better track of file contents (not just file names), so in git a rename is just like any other change, and the full revision history is maintained. My experience is that the migration can be smooth and fairly painless. Developers have to learn a couple of new commands (and there are good git for svn users cheat-sheets). And you're right, any documentation that talks about svn commands would need to be updated. (As an aside, what Moses documentation talks about svn?) Cheers, Lane
_______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
