Three of us have been using git with a shared (git) repository on a server. We've been pushing and pulling to/from the shared repository as opposed to peer-to-peer just as a matter of convenience and familiarity.
I have to say I like the concept of distibuted version control, or more to the point: versioning locally, pushing, and pulling. This is the first I've used such a tool. Mostly I've been using svn for the last few years. We've not tried the svn/git combo pack, just because we did not need or want to use svn in this case.
I also have to say after a couple two three weeks of using git, I am not crazy about git per se. Aside from just the learning adjustment that this is not svn and this is distributed version control, the adjustment and learning about what I would call the "quirks" of git have been somewhat discouraging.
I'd compare some of the cryptic language of git to some of the cryptic error messages a programmer new to erlang sees, or haskell / complexly type inferred languages. Combined with a vocabulary only a kernel linux hacker could appreciate, I suppose. I don't think this language is due to the concepts of distributed version control per se, rather to git's implementation and implementors.
And whatknot.
So git seems to be winning. I've not tried mercurial or other distributed repositories. Is git so good? Or just the one that's winning for reasons other than usability? And stuff.
12 comments:
We're using BZR over here at my small company. We just switched from CVS.
BZR is really, really usable, especially for lots of small, distributed code bases (rather than a giant monolithic app like Mozilla or the Kernel).
I'd give it a try. It's easy to install, and you don't need BZR running on a remote server to use that server as a "source of truth".
With BZR, you have branches in separate directories, rather than in the same directory like Git (with a command to re-orient you).
Anyway, even if you don't go with BZR, it certainly sets the standard for ease-of-use and the developers are quite friendly and helpful on IRC.
Yeah, that's nice and all, but can you integrate it with ClearCase?
You'll definately want to check out Mercurial if you want something fast, reliable and usable.
I've been using darcs for years, bzr for a while, hg & git never. I've never hearda compelling reason for wrapping my head around git's commands. If you are unhappy with git I would look at the other distributed version control systems that are available.
I've been using git for quite a while and I may have become blind to some of the usability quirks. Can you give some examples of the sort of thing you are talking about?
Examples - especially the error messages seem to be indirect. For example the shared repository is on an ubuntu server, and we're using the git ssh protocol to push and pull. Our umasks were not set up correctly for this kind of sharing. The messages were strange, but google found them and suggested ubuntu's default umask could be the problem.
How git presents branches is unusual, maybe the other dvcs provide a more familiar model. Also how directories are treated (or not) is at best new to me having used svn. Other things like not handling symlinks, not merging as well as svn, etc.
I've been using Mercurial for about 5 months now and have nothing but positive things to say about it.
People pick Git for its performance on huge repositories and it's coolness by association with Linus Torvalds.
I've found Bazaar to be very easy to use with clear error messages and I've never had a project so large that performance was an issue. I think my brain would stop coping before Bazaar would!
> How git presents branches is unusual, maybe the other DVCS provide a more familiar model. Also how directories are treated (or not) is at best new to me having used svn. Other things like not handling symlinks, not merging as well as svn, etc.
@Patrick: what do you mean by unusual branches presentation? And git does handle symlinks, and even has some support for handling them on filesystems which does not support symlinks. I don't understand how you can say that Subversion does merging better (even svn 1.5, or pre-1.5 with svnmerge)...
+1 for bzr. There is almost no learning curve moving from svn to bzr. I'm not sure why more people don't use it. Ubuntu's Launchpad offers free bzr hosting as well.
I've gone through the same process you have. I surveyed the DVCS scene, seemed like hg and git had the momentum, and between those, git. I have to settle on the first technology that doesn't suck. So I imported a large subversion repo to git, it didn't suck, and we're using it now.
The motivation was: we had to deliver a branch to a customer, and maintain it over the next few years. Git and DVCSs are all about merging changes from our trunk to the branch. Our process for merging with SVN felt fragile.
I think in many ways it comes down to what workflow you're comfortable with. I've tried mercurial, bazaar and git. There wasn't much between bazaar and mercurial, and they both fitted better with my workflow. YMMV.
Post a Comment