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."
Why Git Is Better Than X.com/ YouTube - Tech Talk: Linus Torvalds on git (yeah, I'm a convert)
It's more than just an moron, it's an nasty, stubborn, selfsentered and selfish moron.
"Our neighbour is an right old git" could be used to describe an elderly neigbour who, say, regularly blocked your driveway because your car got in the way of the sunlight on his garden.
The old neighbour from Dennis, or Victor Meldrew from One Food In The Grave are both fine examples of gits.
It's like a weaker version of the c-word.
If the system you are migrating from manages trees, you should be fine. CVS migration is pretty easy and I understand that Perforce works quite well too (in both directions!). Most of the migration tools are listed in the GIT FAQ.
The places where people are likely to have trouble is migrating from tools that don't understand that there's more than one file. For example, RCS and SCCS both support branches, but in a completely different way to git (branches are per-file, they're not for the whole repository). This means that during conversion, something useful has to happen with them, but the right answer isn't clear to a program. If versions 1.1, 1.1.1.1, 1.1.1.2 and 1.2 of file "foo" exist, then versions 1.1.1.2 and 1.2 are on different branches and either may be the older revision. It's not clear if revision 1.43.1.3 of file "bar" is the same "branch" as "foo" 1.1.1.2 or not. Because RCS and SCCS deal with single files only, it's not possible to find an answer to these questions in the history files at all - if there is an answer, it's just a convention of the user. Essentially what's happening here is that the git import process requires information which isn't represented in the files you're converting from. For what it's worth, migrating from SCCS or RCS to CVS has a similar problem.
Personally, I've migrated from CVS to git for findutils (well, Jim Meyering did the actual migration; he migrated coreutils too). I haven't regretted migrating at all. It took me a long time of using git locally before I was comfortable migrating the master repo, though. As a git beginner the thing I found most worrying was that I found it hard to envisage the effect of the git command I was typing. The thing it took me a long time to figure out is that with a distributed version control system, it's safe to screw up your local copy, as long as you don't push the result.
Quoth Linus Torvalds, "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git." :)
Audioscrobbler
I have migrated to svn many repos from older stuff, like SCCS and VSS. Migration strategies are important, and to decide about them you need to answer a few questions. First of all, ask yourself if git or DVCS is the best option for you, your project and your company. Just don't be led by hype. It may be that a centralized VCS like svn may be a better option. There are tools to make them perform as DVCS, like the plugins git-svn and bzr-svn. Second, ask yourself how much of the project history is needed, if any is needed at all. That may save you lots of time, disk, chaos and entropy. When migrating, it is very important to tidy up the repo. Purge unnecessary files, binaries, archives, branches, etc. I have seen people who use VCSs like a trashcan. Bad practices may sink the repository performance. After migrating, make sure users know how to use the repo and that understand the basic VCS concepts, either generic or specific for the VCS of choice. Try to remove practices and concepts from the older VCS. As you mentioned it, best practices are very important, and they are not easily found on literature. There is more I could say, but I guess by now it's ok.
I always though bzr had the edge on git in terms of being a better DVCS. Is there a reason why the article seems to think that git is the default?
No such thing as 'better' here.
Bazaar was the runner-up DVCS, and rightfully so, but it has both advantages and disadvantages. Git is faster and currently more popular. Bazaar has an easier interface, better GUIs, is more easily extensible (Python), and runs better on non-Linux platforms.
So which you prefer is a matter of what you are looking for.
It's four good reasons.
1. You can use git for any purpose. You have to pay serious coin before you can use Bitkeeper for any purpose.
2. You have the freedom to see how git works, down to every last line of code. I can't comment on whether Bitkeeper also includes this level of freedom.
3. You can make any damn changes you want to Git, without prior approval.
4. You can pass on all these freedoms, and the freedom to use your change, to anybody you want. It was precisely the fact you can't do that with Bitkeeper that led to it being dropped by the Linux developers and replaced with a coded-from-scratch replacement.
Does my bum look big in this?
Tortoisegit. Haven't used it so I can't tell you how stable or complete it is.
I'll pray for your soul. There's nothing worse than a group of managers who think that the world will get better when Clearcase is employed. I swear, that tool seems to be deliberately designed to slow you down.
Git or BK command :
git pull
Clearcase command :
cleartool findmerge -avobs -fversion MYLABEL -merge -gmerge
It's worse than that. The bitkeeper author at one point tried to extend that as a ban on anyone who works for a company that has a competing product with bitkeeper.
I curse more when I use git than when I use Windoz (and those are the only times I curse). Git's design is really that bad (from a user perspective).
Git is fully distributed (with no "authoritative" source), but it doesn't give you any tools understand/manage the distribution of files. If you have a work group with more than a few people, you are constantly asking what repo (and what access method to it), what branch, and what (bombastically long) revision. It's fine for 1-2 people, but then any version control system is fine for a small enough group.
The documentation helps little. When you do "git help merge", you don't @#$@# care that this is the front end to multiple merge methods. You just want the stupid thing to work. If it's a special case, then you'll look for an advanced technique; but you are stuck reading through all this crap trying to figure out what really matters. No offense to the people working on git docs. It used to be awful, now it just sucks. The problem is more in the user interface design than the docs.
There are over 100 git commands, and a command can do radically different things depending the the switches and target syntax. It's more confusing than any other revision control system that I have worked with.
I use git because I have to, not because I want to (like Windoz). After using it for months, I still routinely get stuck trying to figure out the right mix of commands, arguments, and target syntax needed to get common things done.
Git can do some (nice) things that subversion can't, but it creates so many problems that you haven't gained anything.
I've heard good things about mecurial and bazaar. I wouldn't recommend git to anyone I liked (but it's perfect for perl :-).