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:Git links (Score:4, Interesting)
FTR I love hg, and I see no reason to switch to git, even though the whole bandwagon movement seems to have jumped on the git train.
Comment removed (Score:5, Interesting)
Re:If it looks like a tree, you'll probably be fin (Score:5, Interesting)
Right, that was always the weakness of git, and although it's improved I still have problems with its usability (or lack of it). For all the dumping Linus does on Subversion/Perforce and its ilk, they are easy to understand and it's basically always clear what you're doing. I haven't used git for a while, but last time I did it was like a box of sharp knives. Although hard to mess up the remote copy, messing up your local copy was much easier.
Git + Eclipse (Score:5, Interesting)
I'm trying to use git as much as possible --- I'm still pretty crappy at doing anything even slightly complicated with it, but even with minimal skills it's brilliant at keeping track of changes to local directories.
The only problem is that I'd really, really like a decent Eclipse git plugin. I'm used to using Subclipse for SVN, which is fantastic: I can point at a file or directory, say 'Synchronise with repository', and then get a graphical diff of every change and the ability to quickly and easily revert or commit changes on a per-change, per-file, per-group-of-file basis, etc. (And you can do this with any revision, which makes backing out one specific change very easy.) Doing the same with git's command line tools seems terribly clunky by comparison, especially when I'm struggling to remember the syntax, and the fundamentally unfamiliar workflow.
I do use the Eclipse git plugin at git.or.cz, but it's still very crude. The file decoration is invaluable, which lets me see at a glance which files are new/changed/pristine in the Eclipse project view, but actually trying to *do* anything with it is deeply unpleasant --- no synchronise view, no graphical diff, and some weird behaviour like if you point at a file, say 'commit this', you get a dialogue prompting you to commit *all* files. Which is not what I want. And there's lots of UI clunkiness all round, due to simple immaturity.
I've had some luck with giggle, but the UI is pretty bad, and some changes (I forget what; new files, perhaps) don't show up in it, which is a bit awkward. I've had a play with some other GUI frontends but they're all pretty nasty by comparison with Subclipse. Still, the git plugin is getting better with time --- I'm just hoping that Synchronise shows up soon...
My (short) experience with git so far (Score:5, Interesting)
I used to use cvs, subversion and perforce. After switching to git, it feels a lot more powerful, at the cost of more things that can go wrong.
My workflow with subversion was:
- regular update: update, check/fix conflicts, continue work
- commit: update, pick files I want to commit with TortoiseSVN, verify the changes in the diff view, write log message, commit, continue work
On GIT:
- regular update: stash my changes, change to master branch, pull, check for errors or dirty files (mostly endian problems), switch to work branch, rebase from master, check for errors or dirty files, unstash my changes, check for errors or dirty files, continue work
- commit: update, stage the files I want to commit, commit them, verify the changes, push
At several stages some obscure thing could go wrong that I needed to look up in the manual or on the internet, or needed to ask someone who used it for longer. That doesn't mean I think GIT is bad, I just feel it takes more time to be fully productive with compared to older systems. And I miss a few minor things from svn, like keyword expansion or properties.
Re:Bazaar (Score:2, Interesting)
Does bzr provide any attempt to sanitize incremental revision numbers? I know that both Mercurial and SVK have issues where you need to figure out that "my r9342 is your r8929". Git avoids this issue entirely since my repository's 92a560f20e72e4296c782d3fbb4706e6946d6209 is always going to be your 92a560f20e72e4296c782d3fbb4706e6946d6209, assuming you have the same commit of course ;)
Comment removed (Score:3, Interesting)
Comment removed (Score:2, Interesting)
Re:Git links (Score:1, Interesting)
Git works great for small project, no doubt. Not so much for very large projects. You obviously don't work in a corporate or government environment with large projects. Our projects are broken into submodules (independent SVN repositories currently) and that's what I was talking about. Some of our submodules are 20 times bigger than the Linux kernel and there is no way to subdivide them more than that. Our source base really is that big.
In fact, I would argue that your suggestion to create many submodules is a weakness of Git. Lots of submodules just makes things even more complicated.
Mercurial vs. Git (Score:5, Interesting)
Re:Meanwhile... (Score:3, Interesting)
I feel you pain. I'm in the same boat. You can't work with CC effectively without 20-30 helper scripts. Hijacked/checked-out files is major pain. Dynamic views are great feature yet are completely useless.
Though that still doesn't mean you can't use Git like local tool.
I used before RCS (ci and co command) to preserve history of my modifications locally. Now due to various circumstances I moved to use Git locally and it works quite well.
After "ct update" (alias ct=cleartool), you go to directory (and in my case to Linux server) where you plan to work and do "git init" and "got add" for the affected files. I'm type of person who like to commit dozen times a day and Git helps greatly to not to impose my deficiency on others.
Though I'm using Git for about year now, I'm pretty much n00b. Outside of the obvious - git init/add/commit/diff/pull/push/update + gitk - I know very little. That's why it is also very hard for me to understand the usual complain about Git that it is very arcane. Yes, documentation is very poor and still can't catch up with all the features, yet you rarely run into the need for some esoteric function or syntax. Basic commands are pretty much "intuitive".
Re:Git links (Score:4, Interesting)
For problem two: this isn't a real problem with git, but rather with your organization. Multiple projects don't belong in the same repository, it's as simple as that.
I have been wanting to start with Git, but I find it too hard to know what should go into different repositories and what should be in the same.
First example: I might be writing a book in book/ and keep all images in a subdirectory book/images/. I think it is not far-fetched that I might want to work on only the images without downloading all the other, possibly huge, subdirectories.
Second example: Say I write a scientific article for which I compute a lot of numerical data. Then I write a second article, which builds upon the same data. Should the two articles go into the same repository, so that I can easily pull and compile everything at once with all dependencies in place, or should they be kept separately, so that I can work on the first article without dragging the other one along?
Comment removed (Score:3, Interesting)
I tried "git cvsimport" and "cvs2git" (Score:3, Interesting)
Neither worked on my 18 yr old CVS repo (that was populated with 7 yr old RCS files). What I did find was fromcvs [dragonflybsd.org]. I found a couple of bugs, with the author fixed very quickly. It is also fast. My 3.5G CVS repo was converted in about an hour. Both of the others took 10+ hours (and didn't produce usable output). The biggest reason I love it: it allows incremental updates from CVS to GIT. You can run it any number of times and it imports the new stuff. You do need to leave the git repo you are importing into alone (no commits other than the import commits).
I still have more testing to do before we go live, but it's looking very, very nice.
How does it work with non-static IPs? (Score:4, Interesting)
Re:Git links (Score:3, Interesting)
Except if one is simply reviewing a specific file or files - for a code review, debugging, or copying pieces to another project. I do this all the time when helping others on their projects. I don't need (or want) the whole hot-mess...
Re:Meanwhile... (Score:3, Interesting)
Where do people get ideas like this? I use CC effectively with one trivial Perl script. It converts "my feature is on this branch off this label" descriptions into config specs -- raw config specs are too complicated to handle, so you need a layer above them which matches your CM process. Yes, IBM/Rational should explain that to their customers. Or maybe make UCM not suck.
Then you're not branching, like you're supposed to do, and a hijacked file is the *least* of your problems. You cannot use CC as if it was CVS; a dynamic view is not a sandbox if you set it up to silently show other people's possibly incomplete changes.
Use them correctly for a few years, then report back.
Re:Git + Eclipse (Score:1, Interesting)
The thing that I've found with git is that using the command line tools is a thousand times easier than SVNs tools, so the need for a good GUI is much less. Doing diffs, choosing which files to commit, previewing your commits - all those things are really easy to do on the command line with git.
Re:Mercurial vs. Git (Score:3, Interesting)
Last I used Mercurial, I couldn't create a feature branch. I had to clone the whole damn repo. Well, either that or I could create a branch that lives forever, not a good idea if I'm doing a crazy experiment.
In Git, if I want to try something out, I create a feature branch (takes basically no time or disk space) and hack away. If it sucks, I just delete the branch. It's a very nice way to work once you get used to it.
Have they improved branching in hg?
Re:Mercurial vs. Git (Score:2, Interesting)
I've been an enthusiastic Mercurial user for about two years. About a month ago, my mounting frustration had reached the point where I made the decision to switch to git, and now I doubt I'll ever be tempted to switch back.
For example, "git rebase" lets you do basically the same thing as MQ, but they're architected differently. In git, you transmute one, normal whole-tree commit into another; in MQ, you transmute one diff into another. My point is that git's approach also records the old parent, onto which the patch series cleanly applies! I can't tell you how many times I "hg qpop -a; hg pull; hg qpush -a" and in so doing destroyed that information. Not really what "hg bisect" was invented for. And, since each patch isn't actually a patch, you can check it out and get a normal tree with which you could use an external 3-way merge tool (not that you'd normally need to, since git's merge machinery seems to be used for rebase too). Or even just edit it without having to know how to fixup hunk offsets by hand.
I think a lot of it boils down to Mercurial's repository format: Hg's append-only repository format is to a tree as git's is to the flying spaghetti monster. Its a beautiful piece of engineering, but it's simply not powerful enough to represent the workflows real development projects want to use. Just look at the provided Hg extensions: most of them do what they do by slicing and dicing the append-only history. There's nothing inherently wrong with that, but it's not reversible. If you screw it up, you have to clone again. With git, you have other options.
As a brand-new git user coming straight from Mercurial, I have to say the whole "complex UI" mantra is out of date. I remember looking at an old version of git before deciding on Hg -- *that* was a too-complex UI. Now, the command paradigm is just *different* (its not a superset of CVS, like Subversion or Mercurial tried, mostly, to be). No big deal.
Re:Meanwhile... (Score:4, Interesting)
Where do people get ideas like this? I use CC effectively with one trivial Perl script. It converts "my feature is on this branch off this label" descriptions into config specs -- raw config specs are too complicated to handle, so you need a layer above them which matches your CM process. Yes, IBM/Rational should explain that to their customers. Or maybe make UCM not suck.
What about normal diff? CC still doesn't allow to use external diff program. And "ct diff" insists on two files - it can't diff hijacked file against original.
What about normal recursive diff for two branches?
What about patch generator? So that you can back up you unchecked-in changes.
What about change log? Recursive change log showing changes for all files in directory?
How about converting change history into set of patches? To allow easier investigation of regressions.
The moronism with R/O files? All extracted/"ct get -to" files are marked R/O.
And this is from top of my head. For all of that I have scripts. And with the scripts, I'd say, CC isn't half bad.
But to the point of original question, with Git I would not need any of the scripts.
Then you're not branching, like you're supposed to do, and a hijacked file is the *least* of your problems. You cannot use CC as if it was CVS; a dynamic view is not a sandbox if you set it up to silently show other people's possibly incomplete changes.
We do branching and hijacked files are not problem per se. It is just better half CC tools, when given as parameter hijacked file, would simply say "f-off, this is view private file."
In some situations checked-out files are even worse since CC treats checked out files like files on a special branch. Consequently half of CC tools accept the file as parameter, yet show dick but no information about the file.
Git doesn't draw any difference between the files and files in repo. At any time you can do whatever you like with any accessible file/revision.
Use them correctly for a few years, then report back.
Care to elaborate on "correct" usage pattern then?
People tried them in company few years ago and pretty much abandoned them. They are still accessible, yet generally unused. Our CC admins would be happy to know the "correct" usage for them.
You can't index dynamic view - because it contains all possible vobs and all possible files. And I do not want to deal with 150K files of the whole project, I need only 3.5K files belonging to my part.
You can't compile in dynamic view - because even if only dozen of people compile simultaneously, CC server simply dies under load.
Heck, simple "ls" spits on screen bunch of errors every time, because dynamic view can't properly show branch, but shows all files on all branches (readdir() lists all of them). And if file did happen to be not on the branch of the dynamic view, stat()ing it would give you an error.
If you can't do development with them, what else can you do with the dynamic views?
I used in past dynamic views solely for porting semi-automatically (with script) trivial fixes into many branches. For more than that dynamic views are useless.
Please, reveal me the secret: how do I use dynamic view "correctly"? Many people in my company would be happy to know it too.
My usage of Subversion (Score:1, Interesting)
I currently use Subversion to keep track of my private projects. Nobody else has access to my repository. It's solely so I can track changes I make to my own software. That said, is there an advantage to using git? I like having a central repository because I can start working on some changes to code, and if I don't like them, revert back. I also don't really care much about tagging or branching. Every now and then I'll use a tag if I want to take a project in a drastically new direction, so I can easily go back to the previous "good" version if I want to. That's about it.
So, is there a reason to switch from Subversion? I'm not tied to it at all; I just want to use the tool that's best for me.
Re:complexity (Score:3, Interesting)
Lots to talk about here!
The complexity of git robs it of quite a bit of the value of it's features. For God only knows what reason, a 5-6 person project that i'm working on is using git instead of subversion, and only the person who setup the project actually has any idea how to use git.
It sounds like the first person set up the project, and now expects everyone else to just "make it work", even if they're not programmers and have a good understanding of Git. Fair 'nuff.
Now I don't know your situation, but if you're actually in a work situation, the lead programmer (or user, if you're not storing code in this repository) should be giving you guys some kind of help or crash course in using Git. The Git model is quite a bit different than SVN, and it has taken me some time to wrap my head around it -- kind of like learning a functional programming language after working with imperative languages for several years.
It's awesome to have the whole thing where it merges all the changes in a same file together, fairly intelligently, but even the GUI version for Windows has no functional interface for how to deal with conflicts (which should be easily done as a "which bit of code is the proper piece to use here?" instead of jamming diffs into a file.
Which Windows GUI tool(s) are you using? Right now I can think of several -- gitk, git-gui, qgit, git extensions, CheetahGit, TortoiseGit, ...
I think that part of the problem right now is that there is no definitive Git GUI for Windows. Even if the TortoiseGit project gets more mature, users of TortoiseSVN or TortoiseCVS will have to learn a new version-control paradigm and understand some new terms before they'll be able to successfully use TortoiseGit.
Also, the Windows and Linux versions of GIT have several problems interoperating with each other.
Are you referring to line-ending problems? If so, take a look at the "core.autocrlf" attribute. If you're not talking about line endings, and you can't find any help online, I'd just go ahead and file a bug report or hop on the git mailing list.
In short, Git appears to have been designed entirely with features in mind, and not one bit of usability for anyone other than Linus himself.
Oh, I think most people would agree with that -- especially Linus. Of course, I think that this is partially a Plumbing vs. Porcelain issue: a number of geeks love to use a command-line shell, but most ordinary users feel much more comfortable with a GUI windowing environment. Many programmers really like the power they get from using Git on the command line, but some people want something a bit more user-friendly like Easy Git [gnome.org] or a Git GUI.
It is a nightmare for people who only have the need for version control and a handful of people working together. It reminds me very, very much of early Linux, before anyone else besides Linus had been hacking on it.
Yes -- I can see that. The Git workflow is pretty different from that of a tool like SVN. Unless the team leader is willing to sit down with the group and work through examples -- and then also be ready to answer questions anytime during the workday for the first few weeks -- then it's going to be a really rough, potentially unproductive month. Even if they grumble about it, it's probably worth their time to train everyone up front.
You've probably seen this before, but for anyone who's moving from SVN to Git, there's a really good Intro to Git for SVN users [git.or.cz].
Good luck!
Re:Git links (Score:3, Interesting)
I'm a Bazaar fan. That isn't to say I'm not a Git fan, I just prefer Bazaar (by a small margin, for a handful of reasons).
That website makes a really good case, but I think they should remove "Bzr" from the "Cheap Local Branching" section. I could s/git/bazaar that entire section and it would still be almost correct.
Bazaar has a totally different view of branches, but it gives you all the same flexibility as Git. The only thing is that Bzr branches are full copies of the entire repository - so they aren't "cheap" by default. To mitigate this, you simply create a "repository" one directory level above the branch, and then all the branches share data and are very cheap and fast.
Re:Git links (Score:3, Interesting)
Well subclipse was started by a single person wanted to have a decent svn plugin it took the guy more than one year to get to a working level, so it takes time.
Git would be the perfect companion for eclipse, it could replace the local history and the remote version control system but that would mean a proper integration of GIT might be 10 times as complicated because it has to replace both version control subsystems eclipse has.
Also git has several unresolved issues, how are you going to do a server repo browser server side version browsing etc...