Git Adoption Soaring; Are There Good Migration Strategies? 346
Got To Get Me A Git writes "Distributed version control systems (DVCS) seem to be the next big thing for open source software development. Many projects have already adopted a DVCS and many others are in the process of migrating. There are a lot of major advantages to using a DVCS, but the task of migrating from one system to another appears to be a formidable challenge. The Perl Foundation's recent switch to Git took over a year to execute. The GNOME project is planning its own migration strategy right now after discovering that a significant majority of the project's developers favor Git. Perhaps some of the projects that are working on transitions from other mainstream version control systems can pool their resources and collaborate to make some standardized tools and migration best practices documentation. Does such a thing already exist? Are any folks out there in the Slashsphere working on migrating their own project or company to a DVCS? I'd appreciate some feedback from other readers about what works and what doesn't."
Re:The best SCM (Score:2, Insightful)
Re:Why is it soaring? (Score:3, Insightful)
Free software tends to soar.
Re:Why is it soaring? (Score:2, Insightful)
Git is Free and does not cost thousands of dollars. Two pretty good reasons.
Re:Git links (Score:4, Insightful)
If you love Hg, there are no strong reasons to switch to Git. None whatsoever. In the same coin, if you love Git, there are no strong reasons to bother switching to Hg, either. Both are *really good* at what they do, and they do it very well. Unlike, say, SVN, which really is for the i'm-too-dumb/lazy-to-use/learn-something-better crowd.
And it is *trivial* to learn to use both git and Hg at the same time if you already know one of them, so you can work properly on projects that use either one without much fuss.
That said, git is evolving a lot faster than Hg. Which could be a reason to either avoid git over Hg, or to avoid Hg over git, depending on your own view of such matters :-)
Bazaar (Score:1, Insightful)
I haven't tried git, but I think that the pure fact that is developed in raw C and uses SHA-1 keys for revisions makes it a pain in the back.
Bazaar is way more convenient on this. Written in python, easily extensible, and uses easier numeric revisions, like SVN.
Re:strategy (Score:5, Insightful)
DVCS is in concept always better then centralized VCS, since it offers all the same features plus a lot more. However there are things that git handles pretty badly. Binary files are such a thing, you really wouldn't want to keep large binary files in git, since git forces you to download all the history of them, unlike SVN which allows you to only download the latest version. Another thing missing from git is a way to checkout just a single directory or file, when I am just interested in the latest version of a single kernel module its kind of annoying being forced to download the whole kernel source tree.
Until Git Tools are mature, SVN will do just fine (Score:5, Insightful)
I've just gotten fluent with SVN versioning after using it for a few years now. I understand that part of what bothers me about it is what bothers Linus Torwalds aswell and had him write Git and I can follow his reasoning in his famous Google speech on Git *and* I understand the hype that ensues around Git and welcome it. That said, until Git has a neat set of stable mature GUI tools to use with it, I'm sticking with Subversion, TortoiseSVN and/or Subclipse. A mature working toolkit that I know how to handle and that works more or less flawlessly.
Even a toolset like that would've costed thousands ten years ago. That goes to show how far we have come in some areas of the software field.
Re:Why is it soaring? (Score:4, Insightful)
Try pushing a change into another Git repository, then navigate to that repository and run "git status" - git does not auto-checkout changes in the destination repository during a push. It's the user's responsibility to detect this and deal with it. I find that design approach - the idea that the user is expected to spot and deal with the internal behaviour of the tool - to be pretty bad.
At first, I found this pretty unintuitive, however, I now feel that automatically checking out the changes would be a Bad Thing(tm).
Most of the time, repositories you push to will be bare repositories, with no working tree. If there is a working tree present, then presumably someone is actively working on it. Imagine you are implementing some new feature in your local copy, which is all very experimental, and perhaps not even compiling yet. Now imagine someone pushes a major refactorisation directly onto your working tree, which does not merge cleanly. I would find this exceedingly annoying. [You have not yet committed any changes, and so the push does merge cleanly with the HEAD, but just not the working tree]
In addition, I think it would be quite distracting if bits of code changed behind my back, when I wasn't expecting it. Especially if I happened to be editing the file in question when it got updated.
Comment removed (Score:3, Insightful)
Comment removed (Score:3, Insightful)
Git providing access to the latest files (Score:4, Insightful)
You're quite right. It seems to me that Git isn't intended to provide access to the latest versions of individual files. Git, like all DVCS's I know of, is essentially a version-control plugin for your filesystem. The filesystem itself provides the current version you're working with, and so it's only a matter of providing an http server over the directory or something like that. Which is exactly what GitWeb and Trac-Git provide, only they're better.
Re:Git links (Score:5, Insightful)
Unlike, say, SVN, which really is for the i'm-too-dumb/lazy-to-use/learn-something-better crowd.
I'm part of the "SVN is working just fine" crowd. If you want people to switch, being a condescending asshole is generally a great way to prevent that and make them more entrenched.
Frankly, no one, including yourself, ever mentions a reason WHY I should switch. I think you should eat pickles for breakfast! Why? *silence* ... dumb ass.
Until this article, I didn't even know it was a distributed system. I'm still not sure why I should care. I haven't cared enough to look into git because I'm busy, my time is important, and SVN works flawlessly for me. As far as I know, you're just the type of person that needs a high performance sports car to drive back and forth to work.
So, the next time you're trying to convert people to your new religion by calling them imbeciles, you might want to consider throwing in at least ONE selling point before your vanishing attention span drags you off to a new shiny. K? Thx
Re:Bazaar (Score:2, Insightful)
The main difference between Bazaar and Git is that Bazaar only tracks files while Git tracks changes. Git therefore is technically able to merge changes where one developer has moved code from one file to another while another developer made modifications to that code. On the other hand Git can have difficulties keeping track of things if you rename and change a file in one commit.
I switched from CVS to GNU-arch (tla). When GNU-arch was discontinued I switched to Bazaar. The command-line interface of Bazaar is easy to use. For example the symmetry of "bzr push" and "bzr pull" is really nice.
Lack of Windows support is still a big issue (Score:3, Insightful)
Many of us develop on Windows, pushing out code to Linux platforms. Git just isn't an option. Poor support for IDEs, especially Eclipse.
Bazaar has been working great for me. Used Mercurial with success as well.
Monotone (Score:2, Insightful)
Re:Git links (Score:3, Insightful)
The right way to do it, at the photo editing side, is to keep the original photo and define a file format for the edits. *Then* VCS would make sense for them.
Re:Git links (Score:3, Insightful)
Sorry to burst your bubble but most software projects do involve artwork and it makes a lot of sense to version that, too - along with the source code.
Do you think artists never make mistakes? Do you think nobody ever wants to go back to an older version of a button-image after a while because the new one wasn't received well?
Well if so then let me welcome you to the real world.
Re:Git links (Score:3, Insightful)
Re:Git links (Score:3, Insightful)
A source controls systems PRIMARY function is to keep track of how things changed over the history of a project.
So if you have a project that contains binary files like photos as well as code it makes sense to choose a version control system that can handle both at a tollerable speed so they can be versioned together.
P.S. I can think of ways to merge changes in images so if your vcs allows you to hook in custom merge tools you could probablly add image merge support (whether the results would be what you want is another matter of course).