Slashdot Mirror
Git Adoption Soaring; Are There Good Migration Strategies?
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."
This is obviously not true though - it's a general argument against the adoption of any new tool. Otherwise all computer science would still be conducted in FORTRAN IV and Autocode. Any potential switch has costs and risks, as well as benefits. All of those should be weighed.
Free software tends to soar.
"It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
Git is Free and does not cost thousands of dollars. Two pretty good reasons.
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 :-)
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.
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.
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.
We suffer more in our imagination than in reality. - Seneca
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.
You can actually make Clearcase work quite well, without resorting to a baseball bat. The trouble is that you have spend a lot of time and money doing it, substantially more than with any other VCS.
A properly-configured and administrated Clearcase environment is very effective - but not good value for money, IMO. I don't believe there is any other revision control system that can do the build auditing stuff that CC does. Unfortunately, some of the ISO capability maturity model stuff seems to require this. I wonder if any IBM/Rational employees were on the standards boards ..
What you're supposed to do in Git is organize your source code into submodules. This takes very little effort, but you have to do it when you migrate.
SVN does let you check out subdirectories, but that is a strength which is perversely afforded by one of its main limitations. SVN does not track the state of the repository globally. Of course, if you want to track the whole repository state, then you cannot allow people to modify subdirectories independently.
I do typical corporate development, and I don't think centralized repositories are best. I love being able to create my own independent sub-project and ask other developers to contribute to it. What possible reason would there be to not have that functionality ? You do need development and delivery processes to govern where people do work and where it is delivered to, but you'll need those irrespective of which SCM you're using.
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.
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
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.
I'm using monotone. What I like about it is its utter paranoia about data loss. Even data loss because of lost bits on a hard disk. You just can't symc a broken repository with a working one; bit failures will not spread. That said, it's designed for use in development against a test suite -- there's a procedure whereby automated tests can be used to "certify" particular revisions, so that an actual user of the software under development can just automatically download the last certified revision and use that.
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.
factor 966971: 966971
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.
SVK. And you get compatibility with SourceForge repos, and tools like TortoiseSVN and subclipse.
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).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register