Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Git Adoption Soaring; Are There Good Migration Strategies?

Soulskill posted more than 5 years ago | from the git-while-the-gittin's-good dept.

Programming 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."

cancel ×

346 comments

Sorry! There are no comments related to the filter you selected.

Git links (4, Informative)

Anonymous Coward | more than 5 years ago | (#26397085)

Why Git Is Better Than X.com/ [whygitisbetterthanx.com] YouTube - Tech Talk: Linus Torvalds on git [youtube.com] (yeah, I'm a convert)

Re:Git links (4, Interesting)

Bananenrepublik (49759) | more than 5 years ago | (#26397389)

whygitisbettertanx.com claims that mercurial doesn't have cheap branching -- the only advantage he sees git having over hg if leaving aside github. I'm surprised by this statement because I use hg branches everyday. The things he describes can all be done straightforwardly with hg, so I'm asking: can anybody in the know tell me if and how git branches are in any way more powerful than hg branches?
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.

Re:Git links (4, Insightful)

Anonymous Coward | more than 5 years ago | (#26397435)

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 :-)

Re:Git links (5, Informative)

grumbel (592662) | more than 5 years ago | (#26397501)

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

Re:Git links (0)

Anonymous Coward | more than 5 years ago | (#26397551)

Agreed. Those are by far the biggest issues I have personally faced. We have some very large projects (at least 20 times the size of the Linux kernel repository) and pushing the entire history to every developer is not workable. As you mentioned, binaries make it even worse as we often attach the "release" branches to a binary build that goes out to customers.

For typical corporate development I still think a centralized repository is best.

Re:Git links (2, Insightful)

bheading (467684) | more than 5 years ago | (#26397757)

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.

Re:Git links (1, Interesting)

Anonymous Coward | more than 5 years ago | (#26397871)

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.

Re:Git links (3, Informative)

Drinking Bleach (975757) | more than 5 years ago | (#26397635)

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.

Re:Git links (4, Informative)

grumbel (592662) | more than 5 years ago | (#26397687)

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.

Re:Git links (2, Interesting)

bheading (467684) | more than 5 years ago | (#26397773)

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 repository.

Re:Git links (3, Informative)

Drinking Bleach (975757) | more than 5 years ago | (#26397777)

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.

Git providing access to the latest files (3, Insightful)

CarpetShark (865376) | more than 5 years ago | (#26397953)

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 (1)

benji fr (632243) | more than 5 years ago | (#26397761)

Problem two IS a real matter in many projects, it looks like you never had a project divided into smaller chunks...

very simple example : one folder for the code, one for the graphics, one with the html/css stuff and so on...

Thanks for this warning : for me this is a very strong argument against git !

Re:Git links (1)

Drinking Bleach (975757) | more than 5 years ago | (#26397881)

If your needs are so drastic, just split it into multiple projects for each team. You can tie them all together via submodules to make a meta-project git to clone when someone really wants it all.

Really not an argument against git, you're just not thinking hard enough.

Re:Git links (0)

Anonymous Coward | more than 5 years ago | (#26397555)

I expected to find out how Git would be able to replace the X Window System.

Meanwhile... (4, Funny)

MichaelSmith (789609) | more than 5 years ago | (#26397089)

In my day job we are migrating to something totally new...clear case.

(shit).

Re:Meanwhile... (5, Informative)

bheading (467684) | more than 5 years ago | (#26397451)

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

Re:Meanwhile... (1)

vally_manea (911530) | more than 5 years ago | (#26397575)

If it only were that easy to use clear case....sigh In my day to day job we have a lot of >10 line view config specs....

Re:Meanwhile... (1)

bheading (467684) | more than 5 years ago | (#26397731)

Well, to use Clearcase properly you have to write a wrapper script that manages and updates the config specs for you. That's the part that they don't tell you when they're selling it to you. Ordinarily, users shouldn't be modifying the config spec.

I love the way when you change the Clearcase config spec and accidentally enter a typo, it doesn't tell you. So you get subtle changes in your repository that you don't expect. I've seen people spend days trying to figure out what was going on when they accidentally modified their config spec with an error.

Re:Meanwhile... (1)

JamesP (688957) | more than 5 years ago | (#26397607)

The solution to clearcrap is a baseball bat

I swear to God, last time someone suggested Clearcase at my job I said "OVER MY DEAD BODY"

Re:Meanwhile... (2, Insightful)

bheading (467684) | more than 5 years ago | (#26397739)

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 ..

Re:Meanwhile... (1)

JamesP (688957) | more than 5 years ago | (#26397939)

I agree, this reminds me of that false-myth: "USA spend $1M in a pen that work in space, Russians used a pencil"

Another thing I tend to notice: sw companies that use CC WILL GO BANKRUPT

Not maybe, WILL.

Companies where software is not what the company essencially sells or only supports their operation can stand it (pretty much like a benign cancer)

Re:Meanwhile... (3, Funny)

David Gerard (12369) | more than 5 years ago | (#26397787)

I foolishly touched Clearcase at work in 2001 and left it on my CV until 2004. I still get calls from pimps desperate for a Clearcase admin to work in deepest suburban Berkshire for GBP30k. (I'm currently a sysadmin in London on GBP40k.) It's one of those cursed words on a resume - if it's ever on your resume, it'll taint it forever and those are the only calls you'll get.

Re:Meanwhile... (1)

CarpetShark (865376) | more than 5 years ago | (#26397891)

Have you put together a clear, serious, constructive proposal for an alternative that spells out the pros and cons? If you haven't, its your own fault really. But if you have, and they don't listen, then yeah, "shit" about sums things up. At any other time, I'd say find better bosses and quit in that situation, but few have that option at the moment.

Re:Meanwhile... (2, Interesting)

ThePhilips (752041) | more than 5 years ago | (#26397957)

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".

bzr vs. git? (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#26397093)

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?

Re:bzr vs. git? (0)

Anonymous Coward | more than 5 years ago | (#26397155)

No offense, but bzr is not a better DVCS. They both have their advantages and disadvantages, but in the end it's up to decide for the users what they like best. It's not like cvs and svn, where everyone knows that svn is superior.

"Better"? (1)

warrax_666 (144623) | more than 5 years ago | (#26397203)

In what way?

I'll happily admit that I do prefer bzr for its UI, but I hardly think either is objectively "better", whatever that means.

Re:bzr vs. git? (4, Informative)

kripkenstein (913150) | more than 5 years ago | (#26397267)

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.

Re:bzr vs. git? (0)

David Gerard (12369) | more than 5 years ago | (#26397793)

Think of it like this:

RCS = DOS.
CVS=Windows 95.
Subversion=Windows 2000.
DVCS = Unix varieties.

Now, which is the right system to run a web server on?

Slashsphere (0)

Anonymous Coward | more than 5 years ago | (#26397095)

Wow, you're really asking for it...

HAY GUYS (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26397115)


r MM MM MMNMMMM MMMMMMMMM MMMMMMMMMMMMMMMM MMMMMM MMMNM MM M Fuck your mother and your father
r MrMrr'ro',oro',o',oro',o',oro',o',oro', ',oro',o',rrrrr@MM Fuck your mother and your father
rMMrWrM'ro',oro',o'>>,r'ror`rr7MrXrM Fuck your mother and your father
rM,rrrM'ro',oro',o', ro',o',oro',o',oro',or,r'ro',rrrrMrrBr0 Fuck your mother and your father
rMrWrrM'ro',oro',o',oro',o',oro', ',oro',or,r'ro',rrrWMrr0rMX Fuck your mother and your father
rM2rSrMr;r,rXi'ro',o o',o',oro',o',oro', ',oro',o',rrrM7rrii@ Fuck your mother and your father
rMSr@MMrX0'ro',oro',o',rrrrSrrrrr;i'ro',oro',o',rr rrrrMMrrMrM Fuck your mother and your father
rMWMMM'ror`rra0BMMMZo',or`rrXBrrSrrroMMMMMMMMMB'ro ',rrrMrrMrM Fuck your mother and your father
rMMrMMrrrrMMMMM MMMMMMMMMMr'ror`r:MMMMMMMMMMMMMMMMMWrrrMMrMiS Fuck your mother and your father
r MMM2rrMMMMM (o) MMMMMMMMMM rr XMMMMMMMMMMMMMMMMMMMMorBM:MX Fuck your mother and your father
r MMMrrMMMMMMMM MMMMMMMMMMMMM r MMMMMMMMMMMMMMMMMMMMMMrrMMMM Fuck your mother and your father
rMMZrrBMMMMMMMMMMMMMMMMMMMMMM r MMMMMMMMMMMMMMMMMMMMMBrrrrMM Fuck your mother and your father
rMrrrrMMMMMMMMMMMMMMMMMMMMMMM r MMMMMMMMMMMMMMMMMMMMMWrWMrrM Fuck your mother and your father
WMrrirMMMMMMMMMMMMMMMMMMMMMMM rM MMMMMMMMMMMMMMMMMMMM,rrrrrM0 Fuck your mother and your father
MXrrrrMMMMMMMMMMMMMMMMMMMMMM'ror` MMMMMMMMMMMMMMMMMMM'ror`rMM Fuck your mother and your father
MZrrrr7MMMMMMMMMMMMMMMMMMMM rrorZr MMMMMMMMMMMM MMMMMrrXrrrZM Fuck your mother and your father
MMrrZrrMMMMMMMMMMMMMMMMMM; rrMMrMMr WMMMMMMMM (o) MMrrarrrrM0 Fuck your mother and your father
rMrr,rrrrXMMMMMMMMMMMMM rrr:MMMrMMM:r MMMMMMMMM MMrrrr7rrrrM Fuck your mother and your father
rMM'ro',rrrr,M0'ro',rrrrr,,MMMBrMMMMr,rrrrZMMM:rrr raWrrrrrMM Fuck your mother and your father
r MrrrrriirXrrr7rrSr,2rrrrSMMMMrMMMM'ro',rrrrrr2:r'r o',rrrM Fuck your mother and your father
r MM'ro',oro',or,r'ror`r8:MMMMMrMMMMMr;rr;iio',or,r' ror`rMM Fuck your mother and your father
rr MM'ro',oro',o',rrrrrr;WMMMMMrMMMMMrM'ro',oro',o',r rroMM Fuck your mother and your father
rrrr MMM'ro',oro',o',rrrrrMMMMMrMMMMM'ro',oro',o',rrrXM MM Fuck your mother and your father
rrrr 0MMMMr'ror,r'ro',rrrrBMMM@rZMMM;'ror,r'ror`rraMMMM M Fuck your mother and your father
'ror` MMMMMMrMr,rr;'ror,r'ror`ri'ror,r'ror`rirrrrMMMMaMa Fuck your mother and your father
'ror` MrrBMMMMr2rZMrr@rrrrZ'ro',rrr,,rror'rrrMrr;M@rrrM Fuck your mother and your father
'ror` MMrrrM2MMM8MrrrZrrrXMrrrX,rrrrMorrrrrrrMMMM@rrrrM Fuck your mother and your father
'ror` MMrrrMrrrZMMMMMMMMMMMiMMMrrrrrWMSMMMMMMMrZMrrrrMM Fuck your mother and your father
'ror`r MWrrMMrrWrrXrrrMrrriMaXMMMMMMBMrSrr7rr:rMMrrrrMX Fuck your mother and your father
'ror`r MMrrXMM2MMrMrrrMrrr,rrrM' or`rrrrBraMBMrM2rrriM Fuck your mother and your father
'ro',rr M2rrMrr@rrMMMMMMMMMr rMrrMorMMrZMZMMr;MMrrrrMM Fuck your mother and your father
'ro',rrr MrrrMMM0rZrrrMr rMMB7MM2MMrMrrSrrrrrMWrrrrrM Fuck your mother and your father
'ro',rrr MrrrrrSMMMMWSMr rrirrMrrrarMrrrM:MMBrSrrrrMM Fuck your mother and your father
'ro',rrr MM'ro',rrr2XMMMWMMMM0MMMMMMMMMMMMrrrrrrrr2M Fuck your mother and your father
'ro',rrrr MMr:'ro',rrrrrr;rrrrr8'ro',oro',o',rrrrMM Fuck your mother and your father
'ro',rrrrr XMMM'ror`roaM'ror`rr, rrrr;;:'ror`rrMMM Fuck your mother and your father
'ror,r'ro',rr WMM'ror,r' or`rBrrMrr rao',or`rMMMr Fuck your mother and your father
'ro',oro',o',rr MMMr:rr,rrrrMorrXS2,rrrrrZMMMX Fuck your mother and your father
'ro',oro',o',rrr rMMMZMMrrr;rrrrBrrrrrrMMMM Fuck your mother and your father
'ro',oro',or,r'ror` irXS2MMMMMMB8ZMMMMX: Fuck your mother and your father
  and your father
TROLLKORE HEAD, I'M IN YOUR BED and your father
I'M FIZZY FIZZY WIZZY, I'M OFF MY HEAD and your father

Filter error: Please use fewer 'junk' characterso
Filter error: Please use fewer 'junk' characterso
Filter error: Please use fewer 'junk' characterso
Filter error: Please use fewer 'junk' characterso

Adopt a git... (4, Funny)

TapeCutter (624760) | more than 5 years ago | (#26397159)

In the UK and to a lesser extent here in Australia a "git" is akin to a moron.

Re:Adopt a git... (5, Informative)

WarwickRyan (780794) | more than 5 years ago | (#26397175)

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.

Re:Adopt a git... (1)

Yetihehe (971185) | more than 5 years ago | (#26397299)

[Git is] like a weaker version of the c-word.

You mean... cvs?

Re:Adopt a git... (1)

bheading (467684) | more than 5 years ago | (#26397335)

The c-word is still very much socially unacceptable here (and in the US too - how often to you hear it in movies ? very rarely), so I don't see "git" as a weaker version of it.

I'd put "git" alongside "moron" or "jerk". Nobody's going to raise their eyebrows if you say it.

Re:Adopt a git... (5, Funny)

Eunuchswear (210685) | more than 5 years ago | (#26397541)

Yes, but only a cunt would say "the c-word".

Re:Adopt a git... (2, Funny)

MrHanky (141717) | more than 5 years ago | (#26397955)

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... (5, Informative)

Wild Bill TX (787533) | more than 5 years ago | (#26397233)

Quoth Linus Torvalds, "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git." :)

Re:Adopt a git... (0)

Anonymous Coward | more than 5 years ago | (#26397235)

The connotation was intentional:

http://www.infoworld.com/article/05/04/19/HNtorvaldswork_1.html
When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."

Git - "The Stupid Content Tracker"

Re:Adopt a git... (1)

Daniel Phillips (238627) | more than 5 years ago | (#26397869)

My understanding always was, Linus wasn't too proud of having driven a wedge through the middle of the kernel community, that's what the "Git" was about. Now that he went on to change the entire world of revision control, I would say... the pain was worth it. Probably.

Re:Adopt a git... (1)

James Youngman (3732) | more than 5 years ago | (#26397247)

Not a moron really, at least in terms of UK usage. Stubborn and irritating, yes, but there is not really an implication of idiocy. The phrase "stupid git" is quite common and isn't a tautology. The OED rather bloodlessly defines "git" as "a worthless person".

Re:Adopt a git... (1)

arevos (659374) | more than 5 years ago | (#26397271)

In the UK and to a lesser extent here in Australia a "git" is akin to a moron.

Actually, git is more akin to "bastard" or "son of a bitch". You can say to someone "he was a clever old git" without it being considered an oxymoron.

Incidentally, Linus claims he named Git after himself.

Re:Adopt a git... (2, Informative)

TapeCutter (624760) | more than 5 years ago | (#26397499)

GP here or "useless git" as my farther used to say. The word originaly comes from foundry workers in the north of England, a "git" is the bit of metal left on the cast where the hole in the mold was. The original metalic git was useless and in the way. - At least that's how BBC's Time Team tells it.

I wonder if Linus knows?

Re:Adopt a git... (1)

DNS-and-BIND (461968) | more than 5 years ago | (#26397311)

It's still a better name than "The Gimp". Seriously, what was the guy thinking? LOL Pulp Fiction LOLZ!@#!#!@

Re:Adopt a git... (1)

TapeCutter (624760) | more than 5 years ago | (#26397523)

Great program, I ignored disparaging references to the disabled but never noticed the connection to Pulp Fiction and will probably never get it out of my mind now.

Re:Adopt a git... (1)

DNS-and-BIND (461968) | more than 5 years ago | (#26397665)

Never noticed the connection? That's what it's named after, man. They came out in the same year, 1994...I thought it was blazingly obvious. "Har har I gave my software a ridiculous name, now everyone will have to use it"

PS it's not a slur against the disabled, get your head out of that victim-as-hero nonsense. Gimp means...well...how shall I say this? Do you know Mr. Slave from Southpark? A gimp is a leather-wearing gay S&M freak.

Re:Adopt a git... (1)

jackharrer (972403) | more than 5 years ago | (#26397385)

We also have GIMP. I think there's some kind of competition going on ;)

moD 0p (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26397171)

OuT of bed 1n the but now they're

Git more popular than Linux (0)

Anonymous Coward | more than 5 years ago | (#26397193)

Wouldn't it be funny if git were to become more popular than Linux? Linus would be remembered as the Finnish hacker who gave the world a decent source version control system. Oh and he also used it for his own kernel.

we are also going to migrate!!! (0)

Anonymous Coward | more than 5 years ago | (#26397199)

At my job we use subversion, and while I would rather a system with off-line commits, and can live with it.

The problem is that the very upper management (that one that lives in another continent) has decided that we are migrating.... to Perforce.

When we tried to argue against it, that we actually prefer FOSS tools (support & integration being always better), the answer was: "oh don't worry, we bought a company-wide license"

Re:we are also going to migrate!!! (0)

Anonymous Coward | more than 5 years ago | (#26397231)

> At my job we use subversion, and while I would rather a system with off-line commits, and can live with it.

You could use git-svn, I prefer it since it means that your central directory uses subversion which is easier to use for first-time users (also thanks to many GUIs like TortoiseSVN, git is a bit lacking there), but you can still branch and commit as you like locally.
Personally I also use these scripts:
http://natsuki.mplayerhq.hu/~reimar/git-mycommit.sh
http://natsuki.mplayerhq.hu/~reimar/git-updateall.sh

to ease updating of all branches and proper review of patches before finally applying them.

Re:we are also going to migrate!!! (1)

Frankie70 (803801) | more than 5 years ago | (#26397357)

I haven't used Subversion.
I have used Perforce & CVS.
Perforce beats the pants off CVS - no competition at all.

Re:we are also going to migrate!!! (1)

skolima (1159779) | more than 5 years ago | (#26397657)

And by the way, walking beats the pants off crawling with both your legs broken. What was your point?

The best SCM (1, Redundant)

gluliverk (1398195) | more than 5 years ago | (#26397201)

I think the best SCM is that SCM which you known the best

Re:The best SCM (1, Insightful)

James Youngman (3732) | more than 5 years ago | (#26397227)

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.

Re:The best SCM (0)

Anonymous Coward | more than 5 years ago | (#26397289)

Bullshit. I used CVS (and once upon a time, RCS), switched to SVN, and very recently picked up Mercurial, which is simply amazing. If you're unwilling to learn something new, you're missing out on a lot of good stuff. I'm certainly switching all my personal projects to hg. And I'm using it for backing up all of my important small files (encryption keys, documents, etc).

If it looks like a tree, you'll probably be fine (5, Informative)

James Youngman (3732) | more than 5 years ago | (#26397205)

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 (4, Interesting)

IamTheRealMike (537420) | more than 5 years ago | (#26397469)

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.

Why is it soaring? (1, Redundant)

SecondaryOak (1342441) | more than 5 years ago | (#26397215)

I've been working with BitKeeper over the past 3 years. From what I understand Git and BitKeeper share exactly the same concept, all differences being minor ones (for example see http://versioncontrolblog.com/comparison/BitKeeper/Git/index.html [versioncontrolblog.com] ). BitKeeper has been around for a while. Why is Git suddenly so popular? Is it so popular? What has changed?

Re:Why is it soaring? (2, Insightful)

at_slashdot (674436) | more than 5 years ago | (#26397245)

Free software tends to soar.

Re:Why is it soaring? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#26397263)

Git is Free and does not cost thousands of dollars. Two pretty good reasons.

Re:Why is it soaring? (-1, Flamebait)

Lando242 (1322757) | more than 5 years ago | (#26397279)

No, thats one good reason. Being "free" and "not costing money" are the same thing. Don't through around the word free when you mean FOSS or simply open source.

Re:Why is it soaring? (4, Informative)

kyz (225372) | more than 5 years ago | (#26397317)

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.

Re:Why is it soaring? (3, Informative)

anarxia (651289) | more than 5 years ago | (#26397375)

Another reason is that the bitkeeper license prohibits users to work on competing products.

Re:Why is it soaring? (4, Informative)

gmack (197796) | more than 5 years ago | (#26397591)

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.

Re:Why is it soaring? (1)

bheading (467684) | more than 5 years ago | (#26397791)

For most commercial organizations, maintaining (including managing change, testing and QA) or their own revision control software is not an option, so having the source code available is not a big selling point. Sure, it's nice to have that flexibility just in case, but in practice it is unlikely you will need it. And to be honest, I really don't give a damn how git works and the less I need to know, the better. My customers don't pay me to be an expert in Git's implementation.

What is more valuable to a commercial organization is the option to pay someone to fix problems when they arise and provide support. If I have a bug that's causing me problems with development, I want to fix it now. Not to have to reassign a team of developers to figure it out.

So I think your argument certainly applies in the open source world, but not for commercial organizations. That's cool - apples and oranges.

"through" is not a verb. (0)

Anonymous Coward | more than 5 years ago | (#26397383)

Fucker.

"Fucker" isn't either (0)

Anonymous Coward | more than 5 years ago | (#26397445)

Shut up.

Re:Why is it soaring? (0)

Anonymous Coward | more than 5 years ago | (#26397511)

He didn't say free. He said Free.

The Oxford Dictionay says:

free, a. 1. Not in bondage to another. ... 3. gratuitous

Many people us "Free" when referring to 1. and "free" when referring to 3.

Re:Why is it soaring? (0)

Anonymous Coward | more than 5 years ago | (#26397293)

http://github.com

Re:Why is it soaring? (5, Interesting)

bheading (467684) | more than 5 years ago | (#26397431)

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.

Re:Why is it soaring? (4, Insightful)

cdfh (1323079) | more than 5 years ago | (#26397631)

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.

Re:Why is it soaring? (1)

cdfh (1323079) | more than 5 years ago | (#26397661)

Actually, I just noticed that in the above scenario, git just overwrites the major refactorisation when the local working tree is committed. This is almost certainly not what I'd want :-) I was hoping it would force a merge when I commit the working tree.

I think all in all, pushing to a non-bare repository should probably be discouraged.

Re:Why is it soaring? (1)

bheading (467684) | more than 5 years ago | (#26397821)

Now imagine someone pushes a major refactorisation directly onto your working tree, which does not merge cleanly

You deal with that by locking out the destination tree and attempting to apply the merge as an atomic transaction. If it cannot be applied because the user has already begun making modifications, then you abort the transaction and rollback to the point you were at before.

Re:Why is it soaring? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26397553)

1. It does the DVCS work as well as bitkeeper
2. It is free software in both senses of the word
3. It doesn't have a non-compete clause (a very large number of developers don't tolerate such crap)
4. It has reached critical mass (in fact, it is, like the Linux kernel, far above the critical point), and there are so many good people working on every aspect of git (core, enhancements, CLI interface, GUIs, IDE integration plugins, and even "tortoise" crap for the lesser capable) that it is making a LOT of progress, very very quickly.

So, while bitkeeper has superior UI tools, that won't last long. That doesn't mean you're wrong at using bitkeeper in your company, as bk is a far, FAR better VCS than anything else in the proprietary software world.

Re:Why is it soaring? (1, Funny)

ciderVisor (1318765) | more than 5 years ago | (#26397663)

bk is a far, FAR better VCS than anything else in the proprietary software world.

Visual Source Safe is surely the better option if you're developing using Visual Studio.

Re:Why is it soaring? (3, Informative)

David Gerard (12369) | more than 5 years ago | (#26397829)

Even Microsoft don't use Visual Source Sink for their own code. (They use Perforce by preference.)

Re:Why is it soaring? (1, Interesting)

bheading (467684) | more than 5 years ago | (#26397863)

VSS is probably one of the worst VCSs ever conceived, worse even than SVN. You clearly have a very limited experience of real-world team oriented software development.

Re:Why is it soaring? (1)

bheading (467684) | more than 5 years ago | (#26397855)

If you think that the the four points you raised are relevant to a commercial organization, then you probably haven't worked in one for very long, if at all. Cost of ownership is what is important, not the cost of the tool. And since the set of companies working on VCS tools is a small subset of the set of all companies doing software development, the non-compete clause (which is common enough in the commercial world) isn't a problem either.

And "critical mass" as in lots of cool bells and whistles is not as important as stability, ease of use and reliability. Open source projects are not driven by commercial concerns, but by whatever the maintainer of the project thinks is cool and whatever a programmer decides would be fun to implement. You're giving away your time for free - why would you spend it doing boring stuff like fixing hard concurrency bugs instead of adding whizzy cool things ?

That is all fine - I am not saying that open source projects must be driven by commece - but this is a limitation that you need to be aware of when you (in a commercial role) decide to adopt open source tools. Of course, there are many many cases where this all works out fine - Linux itself being one of those.

Re:Why is it soaring? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26397667)

Actually, behind the hood Git is technically way superior to BitKeeper.

The only thing they really share is using the
distributed model. In other respects, Git is to BitKeeper like Svn is to CVS. Like CVS, BitKeeper uses per-file revisioning, with all of the subtle problems it entails. Git, like Svn, uses a solid approach of revisioning trees.

Another thing is that Git understands branches, BitKeeper only has the concept of trunk. This means no cheap branches, and makes merging a pain (you can't even try to _compile_ a merge to check your conflict resolutions before you commit).

The only reason to use BitKeeper is that your revision history is locked into its proprietary format.

  - Kristian.

Re:Why is it soaring? (1)

David Gerard (12369) | more than 5 years ago | (#26397811)

Because, being free software, people can actually use the damn thing.

strategy (4, Informative)

carnicer (1449311) | more than 5 years ago | (#26397251)

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.

Re:strategy (3, Informative)

bheading (467684) | more than 5 years ago | (#26397441)

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.

Re:strategy (4, Insightful)

grumbel (592662) | more than 5 years ago | (#26397549)

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.

Re:strategy (1)

carnicer (1449311) | more than 5 years ago | (#26397749)

i can concede that in *concept*, D-VCS is better than C-VCS (as you put it, C-VCS is a subset of D-VCS). but when it comes to getting things to work, have non-geek developers use it, have multiplatform tools, interoperability, etc, or simply, that the company does not *need* or *want* to use a D-VCS (i.e. does not want the source code to leave *easily* the office), a popular C-VCS like svn may be the choice. also, the learning curve. i have read recently that git's has been flattened in the last year (last time i tried to learn to use it), but if it is already difficult for some developers to use svn, let alone try git (or bzr). fyi, i am using bzr as my D-VCS of choice (was much easier to use than git). i won't of course say that C-VCSs are suitable for all the projects / companies.

Re:strategy (1, Troll)

drinkypoo (153816) | more than 5 years ago | (#26397571)

As just some schmuck who downloads sources over the internets for compilation, I will give my POV: git is shit! So far I have done pulls from cvs, cvsnt, svn, git, and mtn that I know of. Of these, the only one worth one tenth of one shit from the user's perspective is svn. Why is that? Because every other remote source code control system will happily corrupt your copy of the repository the majority of the time that there is some communications problem. In the case of svn, you can at least almost always resume a get. svn was invented specifically because cvs couldn't do this properly; with cvsnt it is possible to complete the get with a bunch of sub-gets. Monotone and git both do a WHOLE BUNCH of transfer before actually even sending any files, so if you have users on slow links, they are NOT repeat NOT a fit for you.

If you will never open up remote access to your source, then perhaps any repo will do for you. But if you plan to open up remote access, PLEASE do not use anything other than svn. Subversion can be painful too (why they couldn't create .svn/tmp directories in the new version instead of just failing because they weren't there, I don't know, but I suspect it can be traced back to developer laziness.)

I want to use git (4, Funny)

alexibu (1071218) | more than 5 years ago | (#26397331)

I have watched Linus talk about git on google tech talks, and am inspired to use it.
Unfortunately I think I need a tool like TortoiseSVN for git because I am a git.

Re:I want to use git (4, Informative)

anarxia (651289) | more than 5 years ago | (#26397413)

Tortoisegit [google.com] . Haven't used it so I can't tell you how stable or complete it is.

Git + Eclipse (5, Interesting)

david.given (6740) | more than 5 years ago | (#26397487)

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...

Re:Git + Eclipse (0)

Anonymous Coward | more than 5 years ago | (#26397851)

Funny. I never saw anything like these GUI issues mentioned on the mailing list. So you chose a particularly ineffective way to change the clunkiness.

It's not so hard to do (2, Informative)

bheading (467684) | more than 5 years ago | (#26397491)

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.

Bazaar (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26397521)

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:Bazaar (1, Interesting)

Drinking Bleach (975757) | more than 5 years ago | (#26397561)

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 ;)

Re:Bazaar (3, Informative)

Anonymous Coward | more than 5 years ago | (#26397961)

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.

My (short) experience with git so far (5, Interesting)

JensR (12975) | more than 5 years ago | (#26397529)

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 (4, Insightful)

Qbertino (265505) | more than 5 years ago | (#26397565)

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 (5, Interesting)

rpp3po (641313) | more than 5 years ago | (#26397915)

I'm working on the OpenJDK source tree through Mercurial. I couldn't be more satisfied. The tools are well structured, very easy to use, stable, fast and well documented. I don't miss any feature. Could anybody, who tried both and prefers Git, list some advantages of it over Mercurial? To me it just seems like a Git done right without the hype and too complex UI.

Darcs (1)

brainnolo (688900) | more than 5 years ago | (#26397941)

I am using Darcs [darcs.net] and it seems to do the job. Is strange that it isn't even mentioned cause it has been around since quite some time and is pretty mature. The only problem I am having with Darcs is huge resource consumption (a copy of the repository is on a VPS with 256mb RAM, no swap) but you can move a repository by just copying it somewhere else (even across systems) without problems. What are the advantages of using Git/Mercurial/Bazaar? I think I need to mention that I am developing on OSX (but a copy of the repository is on a Linux system).
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>