Slashdot Log In
Git Adoption Soaring; Are There Good Migration Strategies?
Posted by
Soulskill
on Sat Jan 10, 2009 05:15 AM
from the git-while-the-gittin's-good dept.
from the git-while-the-gittin's-good dept.
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."
Related Stories
[+]
Developers: Perl Migrates To the Git Version Control System 277 comments
On Elpeleg writes "The Perl Foundation has announced they are switching their version control systems to git. According to the announcement, Perl 5 migration to git would allow the language development team to take advantage of git's extensive offline and distributed version support. Git is open source and readily available to all Perl developers. Among other advantages, the announcement notes that git simplifies commits, producing fewer administrative overheads for integrating contributions. Git's change analysis tools are also singled out for praise. The transformation from Perforce to git apparently took over a year. Sam Vilain of Catalyst IT 'spent more than a year building custom tools to transform 21 years of Perl history into the first ever unified repository of every single change to Perl.' The git repository incorporates historic snapshot releases and patch sets, which is frankly both cool and historically pleasing. Some of the patch sets were apparently recovered from old hard drives, notching up the geek satisfaction factor even more. Developers can download a copy of the current Perl 5 repository directly from the perl.org site, where the source is hosted."
Submission: Git adoption soaring, migration strategies needed by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Git links (Score:4, Informative)
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.
Parent
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 :-)
Parent
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
Parent
Re:Git links (Score:5, Informative)
In case you were looking for answers rather than abuse: I have used both. For me git does what svn does, plus the following in order of most important first.
Of course, this is for me, and all points might be irrelevant for you.
Parent
Re:Git links (Score:5, Informative)
Some things git is bad at:
- no of partial cloning, so a big history means lots of stuff to download, this is especially bad when it comes to binary files
- no way to download just a single file or directory, a user always has to clone the whole repository
Parent
Re:Git links (Score:4, Informative)
For problem one: git clone --depth 1 (or however far back you want your history to go); note this severely cripples git's abilities and isn't very useful at all unless you're on dialup still.
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.
Parent
Re:Git links (Score:5, Informative)
Problem two *is* a problem with git, it has nothing to do with how you organize a project, since you can never guess what a user might want. Simple example: I would like to look at the latest version of a file in the linux kernel, with git I have to download the whole beast when all I want is a single file, which is neither pretty nor fast.
Parent
Re: (Score:3, Interesting)
That is a fair point - git isn't good for looking at isolated parts or individual files in a repository. But I see it really as a matter of optimizing for the common case. Normally, I need to see the whole repository. Normally I don't need to just look at one file. Git will checkout an entire repository along with all the history faster than SVN will, in the tests that I did.
BTW if I just want to look at one file in Git I use the web interface. That gets around the problem by querying into the main reposito
Re:Git links (Score:4, Informative)
I hadn't really thought of that, I had assumed you were referring to Subversion's rather common case where multiple projects are stored in the same repo, and you checkout different directories to access one of them.
Anyhow, most, but not all, public git servers have a gitweb or similar attached, which will at least let you browse and download files from the tree if you need to. For example, grabbing the latest README of Linus' Linux tree can be had via http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=README;hb=HEAD [kernel.org]
Git itself doesn't provide any mechanism for it, however, but it's fairly unusual to be interested in a specific file rather than the entire project.
Parent
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.
Parent
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?
Parent
Re: (Score:3, Insightful)
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 th
Meanwhile... (Score:5, Funny)
(shit).
Re:Meanwhile... (Score:5, Informative)
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
Parent
Re: (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
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.
Parent
Re: (Score:3, Insightful)
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
Re:Meanwhile... (Score:4, Funny)
Parent
Adopt a git... (Score:5, Funny)
Re:Adopt a git... (Score:5, Informative)
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.
Parent
Re: (Score:3, Funny)
In the language Dogg [wikipedia.org], the word 'git' means 'sir'. So one would politely ask a stranger: 'Cretinous pig-faced, git?', meaning 'Have you got the time please, sir?'
Then there's this [youtube.com].
Re:Adopt a git... (Score:5, Funny)
Yes, but only a cunt would say "the c-word".
Parent
Re:Adopt a git... (Score:5, Informative)
Parent
Re: (Score:3, Informative)
I wonder if Linus knows?
If it looks like a tree, you'll probably be fine (Score:5, Informative)
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 [git.or.cz].
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.
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.
Parent
strategy (Score:4, Informative)
Re:strategy (Score:4, Informative)
It may be that a centralized VCS like svn may be a better option.
I cannot conceive of a scenario where this is true. In any case, you can use Git or any other distributed tool as a centralized VCS if you wish. Just tell all your developers to merge their code into the central location, and not to clone from each other's repositories. Dead easy. Although the idea that anyone would seek to make those restrictions makes no sense.
Parent
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.
Parent
I want to use git (Score:4, Funny)
Unfortunately I think I need a tool like TortoiseSVN for git because I am a git.
Re:I want to use git (Score:5, Informative)
Parent
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...
It's not so hard to do (Score:3, Informative)
It's not surprising that developers increasingly favour distributed version control. It's a much more flexible way to work - and if you need to continue working in a centralized way, you can still do that.
If you're migrating to Git, there are a few things you need to account for. Do you want to migrate the history, or make a clean break using the current head of the tree ? Migrating the history is usually hard if it is in a commercial tool, since commercial companies quite obviously do not design their tools to make it easier for you to abandon them (some provide export tools). If you choose not to migrate the history, you have the issue of having to keep the old revision control system around to debug/fix/review older releases.
You need to be clear about your decision. Import some example code into Git (perhaps from your existing repository), put it on a server and ask your developers to play with it to make sure they're happy with the feel and that they're confident they can work with it. Make sure you practice doing things like merging conflicts and merging older maintenance branches. If you do this right, most of your developers should be fairly enthusiastic about the switch when it comes. Make sure you account for Windows users - Git isn't so hot over on Windows and I don't think there is an official stable Windows release yet.
Other than this, there's really very little to it.
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.
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.
Mercurial vs. Git (Score:5, Interesting)
Git Adoption Soaring? (Score:3, Interesting)
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.
How does it work with non-static IPs? (Score:4, Interesting)
@#$@#$ git! (Score:5, Informative)
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 :-).
Re: (Score:3, Insightful)
Free software tends to soar.
Re:Why is it soaring? (Score:5, Interesting)
I think it's more popular for one of the same reasons that Bitkeeper initially became popular - it's being used by Linus for the kernel. Getting Linus to use one of your tools is one of the best marketing coups you can land. Outside of this, Bitmover is a small company and it's hard to see how they would have gotten the kind of exposure that they did with the kernel. That said, they seem to be surviving just fine today.
The other reason that it's popular is because it's free. This is fine for open source projects. In the commercial land, managers tend to underestimate the importance of good revision control tools and processes, and the importance of tools which make it easy to build and enforce those processes. Bitkeeper (and some of it's competitors) go to a lot of effort to provide both tools and processes. Git is not so good at this. Other tools that are not good at this include Clearcase (although UCM is an attempt, albeit a controversial one) and CVS.
And I wouldn't say that Bitkeeper and Git are the same. The underlying design concept - distributed version control, changesets, and the benefits that flow out of this eg proper merge tracking and a greater degree of determinism - are the same. Bitkeeper has much better GUI tools, and it's a lot more user-friendly; the command interface is coherent and consistent, and the commands are simpler and easier to remember, options that do similar things are the same across different commands. For example, the "-r" flag always refers to a changeset number, in any command that accepts this parameter. I used BK on a project with between 20 and 45 users; it never once corrupted the repository and there wasn't a single time when the server went down. There were a few times when things were weird when new users unfamiliar with the tool broke their repos, but that stopped after a couple of weeks. The real benefit is that it makes it very easy to see who broke what, and how - whether it was during development or during a merge.
Git isn't friendly or forgiving at all, and you need to really know what you are doing. There are operations that are very dangerous, like the rebase operation; BK does have an equivalent but it incorporates some basic measures to stop someone from messing up the repository they are pushing to.
Additionally, Git will break things in unexpected ways. 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.
Linus says that anyone who thinks Git is hard to use is an idiot. Idiocy is not the problem here. The developers in the organization I work in do not want to have to know or care about how the internals of the tool work. They want to cut their code, merge it and integrate it as quickly and as effectively as possible. BK easily beats Git on this measure. On the other hand, Git is far and away the superior open-source revision control tool. Anyone who thinks that Subversion is better just doesn't get it.
Parent
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.
Parent
Re:Why is it soaring? (Score:5, Informative)
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.
Parent
Re:Why is it soaring? (Score:4, Informative)
Parent
Re:Why is it soaring? (Score:5, Informative)
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.
Parent
Re:Why is it soaring? (Score:4, Informative)
Parent
Re:bzr vs. git? (Score:5, Informative)
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.
Parent
Re: (Score:3, Informative)
huh ? mercurial has no issue with revisions numbers, revisions are indexed with a hash just like git . The sequencial numbering is available as a convenient alternative for referring to a rev, that's all.