I didn't participate in such transitions, but one of my past employers did such migration already in OO.o 1.x times.
They have employed rather pragmatical approach and made (partial) migration in several phases. At first they mandated that all employees have OOo installed. Then whole R&D (and all of internal documentation) migrated to OO.o. That was rather painful yet rewarding. Then those who didn't need M$O ditched it. At the end of migration we had most of personnel using OO.o (rather successfully; it's when I joined the company) - only of sales (minority in engineering company) and test department were using simultaneously OO.o and M$O.
I'd rate OO.o for technical purposes higher than M$O since many features in former are implemented much simpler than their counterparts in M$O. Comparing old documentation M$O template with newer OO.o template I found that OO.o template was missing all the black magic people had to employ to make derived M$O documents easy to edit. OO.o's outlines alone were saving lots of time. Export to PDF was beautifully solving problem of communication with business partners.
All in all, I'd say, that using OO.o internally is pretty easy. Yet company has to be ready to have also number of M$O installations to be able to read/edit documents from partners. Hinting your partners that you are using internally OO.o and PDF/SWX/ODF are preferred formats might lead to some nice surprises: many companies at least pilot OO.o internally and pretty happy to send you documents in your preferred format.
And piece of advise: do NOT mix OO.o and M$O documents: binary.DOC format compatibility is all but myth. Implement OO.o where you can clearly draw a line between internal confidential documents and external/public documents.
Nothing directly related to RTFA. The reporter goes into excuses that he never heard of the Linux thing but since he is now enlightened by results of Google search, he really eager to learn about the Windows alternative.
Ironically I know such people. Also I know well their reaction to problems with technology. In fact it is very predictable: they immediately call me.
I can't imagine that somebody lives in a place where there are no knowledgeable about technology people. If not to show how to use Ubuntu - but at least to help buy/install Windows. And with modern primitive (simpler than "simple") installation procedure of Windows you do not need to have any slightest clue about computers or OSs.
Anyway I look at the story conclusion is the same: she simply wanted to skip classes and looked for excuse.
Actually I'm surprised that no M$ conspiracy theories were yet thrown in.
What is actually plausible: some M$ partner (e.g. same guys who supplies M$Windows/Office to her school) might wanted to FUD about Linux and just inflamed the story.
OpenVMS had both "impersonation" and "capabilities" (or "privileges") (See here). Where from they have actually came to WinNT.
Capabilities might be hard to spot, because in *nix universe (of which VMS is distant relative) they are bound to access to special files (normally under/dev in *nix and magic file names in VMS). By defining who has access to the special files, you define their capabilities.
I'm not a VMS historian so I cannot tell when the features went into the OS, yet AFAIK most of VMS development and core feature were stabilized by mid 80s. E.g. ACLs in VMS apparently appeared in 1984. Probably googling for "vms history" would bring more info. (Name change to "OpenVMS" happened in 1991.)
Other systems are also designed to protect system files from being modified by an application (say, a virus), but IPAT's patent goes one step beyond that, with a system that can prevent programs from modifying a user's files.
The "one step beyond that" part what is called "impersonation," when program works in context of a user. Impersonation is word from WinNT universe, though setuid is pretty much the same thing.
It's needless to talk about prior art. There are piles of it.
Oooo.. dangerous thinking. The complete lack of administrative overhead seems like a great panacea.. until you realise that you are essentially side-stepping any corporate data retention policy, side-stepping the benefits of corporate IT support and data protection policies, and increasing risk of partial data loss.
Load of bullocks. I'm working in corporations for past 5 years and yet to see any "benefits of corporate IT support." Corporate IT is generally some bunch of management-ass-lickers. They do not care about mere mortals developers.
As to retention policy and data protection, for past 4(?) years, my $HOME is always and completely backed up - and that's includes all my repos. In fact it is volume over NFS mounted from huge NAS RAID.
Or are you suggesting that, via forced git pulls from every single developer to every single developer you are thus creating a redundancy strategy better than the typical corporate IT backup/disaster plans?..
You are severely behind times. See above.
so how is it that you are going to force all developers to do a git pull, or at least a push to some central machine on a regular basis without actually implementing *some* sort of IT-supported machinery?
When developer gets assignment (e.g. implement feature), he is also responsible for delivering on the assignment. In CVS/etc it is check-in to global repository. In Git this is push into global repository.
Difference? None.
Well, in fact there is one. In CVS/etc developer is responsible for integration of feature with rest of the system. If he wasn't bright enough and f***ed up rest of the system in the process - whole R&D is f***ed up. In Git, "push" remains local to the "global repository" and if somebody broke something, one can always review and reject the pushed changeset - even before anybody can pull it. Or even if you cloned the global repository, you still can remove the changeset locally. In Git there is very little overhead of maintaining repos which work only as staging area: where to others can push and where you (as e.g. release master or tester) can compile/test the changes. After changeset was cleared by release/test teams it can be pushed further into real global repository, where it would be visible by others.
Check that out - "Integration Manager Workflow". This is pretty much ideal workflow, which in past I have seen people numerous times tried to implement using centralized systems. And before DVCS I have seen only one solution which can be called "working."
Company can't fire people left and right. Because it's Germany.
In past my employer tried to "restructure" the company, yet some slackers - who were fired with the premise that their department isn't needed anymore - sued employer and got their positions back.
But also, from my experience even with most competent R&Ds is that you always have some people who "do not get it."
"Backbone" of R&D often are some spineless bunch of people living on payroll and living solely for the payroll. They have no opinions, they have no ideas. You can only set rules and give them assignment. Very manageable bunch, yet in the end - unmotivated and incompetent. And company-wide deployed tools are always selected looking back at the "backbone". I call it "backbone," because management see that as "backbone". Competent people who have opinion often are quite unmanageable (e.g. me). Managers do not like people like I am - yet they depend on us: because we give ideas to move product (and company) forward.
And then we come to a paradox. Company selects some stupid tool - because its level fits to average level of competence in R&D - and they tell me that since me is smart as I'm, I could figure my way around. And generally I do.
Like it is now with ClearCase in my company. From all CVS clones I worked before, CC is probably one of the best. Yet, it is a CVS in its heart. But I'm already (slowly) implementing some DVCS-like features. I already can "push" patch into branch (provided that there are no merge conflicts).
If you're talking about "cleartool update" and hijacking files, then you're using snapshot views. Ungh. They suck. Stick with dynamic views, and get your winkins to work, which usually means major makefile hackage. It is worth it.
Unfortunately, our main project is very large and when lots of people work with dynamic views, CC server simply dies under load. That was already tried right after CC deployment.
That said, I'm different company now and going through a git vs. subversion selection process. For some reason I can't get motivated by subversion. Git seems like a whole lot more fun. Not a very scientific or profession attitude, but that is also the reason I first switched to perl oh so many years ago.
If your company needs good Windows support - then you have to go with SVN or Hg (Mercurial) as only usable options. Git as *nix tool in its heart not very good on Windows. Folks with "msysgit" try to bring the power of Git to Windows and from comments I can judge that it mostly works, yet you shouldn't expect SVN level of integration with Windows out of it.
On other side, if development happens exclusively under *nix, then Git (or Hg) is really great tool. Especially if compared to SVN.
Unfortunately, I have experience only with SVN. Several of my past employers use it without major problems. I use Git for all of my pet hobby projects and pretty happy with it. I'm no novice to DVCS and I have used before Arch and Darcs. Darcs is very simple and Arch is very very powerful (and complicated). Git is good compromise between the two: simple things in Git are very simple but some complicated things are darn complicated. (Though I'm still missing Arch's archive system, which allowed to (in a way) partition version information so that size of currently used repository stays within some sane limits.)
You can't work with CC effectively without 20-30 helper scripts.
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.
Hijacked/checked-out files is major pain.
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.
Dynamic views are great feature yet are completely useless.
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.
It may be that a centralized VCS like svn may be a better option.
I cannot conceive of a scenario where this is true.
You need to work shortly in some large corporate R&D. Average level of corporate developer is quite low. You wouldn't want to give all the power of Git (or any other DVCS) to them because quite quickly it would turn into total mess.
Also, I have seen that some not very bright developers are always on look out for features to abuse. E.g. I have colleague who always compiles whole tree (that takes about 2 hours). Whenever anybody ask him what he did on any particular day, he normally says "oh, some flags were set not right so I had to recompile." Adding here "oh I messed up my tree and had to clone again" wouldn't help the situation.
In corporations, you have not choice but to limit what developers can do with their time. Unfortunately in large R&Ds you always have to align on lowest competence level.
Although hard to mess up the remote copy, messing up your local copy was much easier.
Can't find the quote from Tom Lord (GNU Arch (tla) author, one of the first DVCS), but he was saying something like: in centralized systems, only admins have full power of the versioning, normal users are treated like economy class.
After migration from centralized system to decentralized, one has to stop for a moment and realize that now everything can be done, everything is possible: there are no more big brother behind your back. This is great power and at the same time great responsibility. But thanks to the fact that you ruin only your local sandbox, that "great responsibility" bit can be easily ignored, leaving you only with "great power."
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.
Can't tell for SVN/Perforce, but I can tell for some other centralized systems. It is not so very clear what you are doing there either. Most centralized systems have heaps of scripts running server-side which might actually recast any command you are issuing into something completely different.
But as I have mentioned above, in centralized systems you can do much much less with your repository. Decentralized systems provide much more functionality and that gives rise to the confusion. It's only natural.
To me personally, main advantage of systems like Git or HG or Arch is that there is literally no administrative overhead. (Well, truth to be told, Arch has some.) If you have well organized development with many people involved, then the overhead of setting up and maintaining centralized repository isn't that great. But in my case of lone hobby developer, set up of SVN server, integration with Apache - are all just time wasters. I have started reading SVN documentation but it was already too late in SVN life cycle and documentation became very very fat. But with Git all I need to do to start new project is "mkdir fancy-project; cd !$; git init" and then just move files over. And, most importantly, performing backup is as easy as "git push".
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".
[...] then I think it will be hard to keep developers interested in doing kernel work - it will seem too much like real work, but unpaid.
Well, it was well advertised before that kernels have little to no interesting challenges - all problems are well known and 30+ years of research is easily available.
Frankly, I'm pretty happy that Linux reached such level of stability. Perl is in the same state: after 5th release, there were very very few major changes. But why to changing anything if it works well already??
Also, stabilization of core Linux means that developers have a chance to rethink many design decisions and correct them. Before, Linux was like in haze to catch up to the level of many commercial OSs, with much much longer histories. Now it firmly stands above most if not all kernels, though as OS (GNU/Linux, distro, etc) there is lots of work ahead - work which can be done now because there is such good stable foundation.
Looking back, I think change of development model during 2.6 series was genius decision. Linux had grown up and doesn't need pampers^W version changed every year anymore.
In 3rd world people are saving by switching, since Linux can be customized to run on less resources. E.g. Linux Terminal Server is much much resource savvy compared to Windows Terminal Server.
And a lot of people will not be happy that they can't do X like they did before.
I'm pretty sure that Vietnam has its own ISVs. And the move - is the huge investment into ISV sector. For government it's a huge win too: more taxes.
And if they need support on some feature you can't intimate a US Open Source Developer by saying you are from the government.
Do not be silly. US != World. Local ISVs can do it and there are lots of Linux consultancies around of world. Asia is not that backward as many CNN/FoxNews watchers might think.
This is huge chance for local business to cash in - in long term. If gov't is serious, I'm sure they wouldn't let the chance to slip.
At least with Microsoft and you are a big customer they will bend over backwards to help you.
That's big lie. They will "bend over backward" if you have enough money to pay them for that. Otherwise you are on your own.
M$ can and does something on their own - but they rarely listen to feedback. Generally, in M$ ecosystem, burden of backward compatibility is on integrators and ISVs. My friend worked for such company in past implementing features (normally using ActiveX) from new M$ products for older M$ products (and vise versa) as well as smoothing integration with 3rd party software. Imagine: huge business built around solving problems created entirely by M$ development strategy.
I do no think that has to do anything with Linux as much as with Micro-Soft putting more pressure on 3rd world governments to curb piracy. It is hard to put pressure on commercial entities there, but government (vulnerable to external political/economical influence) is always easy target.
IIRC, Vietnam tops the list of most pirating nations. What is not surprising with monthly wages in range of $50-100. Windows even at $20 is still too expensive.
Re:I also give the book a 9...I own it
on
Ubuntu Kung Fu
·
· Score: 1
I've never had a problem that ubuntuforums.org didn't have the answer to.
To ask a question is also a skill which requires some knowledge. Or how old saying goes "a good question contains half of the response."
I haven't read the particular book, yet generally such books a great starting point - a stepping stone which helps to start asking questions.
Properly-managed centralized version control allows anyone to check in at any time.
It doesn't need to be "properly-managed." You can actually do that in SVN already (modulo merging).
You simply have to forget about performance and start getting used to coffee breaks. That's from my personal experience.
And worst case performance of SVN can be really really bad. Colleague of mine updated important headers - and bunch of related files. Everybody got e-mail in the morning and started update. After waiting 30 minutes for svn to finish (normally took ~5minutes) I decided to make my lunch break earlier. Real life story.
Branching in SVN also works. But merges - especially on large project are really nightmare. My past employer actually set sort of record: check-ins were prohibited for two weeks straight so that people can actually check-in fixed results of merge. That's reality of how it works - and you can't make it better in centralized system. Unless of course you can get one of those rare magic wands for your "management."
Properly-written centralized version control software allows anyone to save checkpoints at any time without requiring access to the server.
That's nonsense. The whole point of centralized system that all actions are recorded at central location. (So that they e.g. can be backed up centrally.)
You apparently have no slightest idea what it takes to create your own tag or branch in centralized system - and what kind of performance impact it has on *every user*. But even if we leave performance issue aside, with R&D >50 people you have to be ready for very very serious clashes of tag/branch names. They are all global because they are all in central repository, you know.
That's why pretty much every sane company using centralized SCM have strict rules that only very very few people can create tags/branches.
Centralized systems do not scale on user number. That's pretty much established fact. There is no point to argue on that. But it's not that you had any arguments to begin with (idealistic crap doesn't count). Frankly, I'm also not good in argument department: it's just I worked with CVS/SVN/friends more than 7 years now.
Unless the revision control system's performance is dreadful I think that all files should be in revision control.
I have to agree. Or rephrasing old saying: a not-checked-in file doesn't exist. (Original by my colleague is "a not-checked-in source code doesn't exist" after several weeks of nightmares trying to reproduce past test case.) Referring to the fact that if file is not under revision control, then you do not have any control over the file.
Or in other words: if you put blobs into SCM, forget about performance.
Subversion is centralised, based on a single server for the repository, and therefore suitable for corporate use.
What is actually big big lie repeated over and over again. So most think it is true.
Just recall all the pains of branching - and merging (and loosing all revision history from the branch).
Or worse - having no revision control for weeks or months. Since you can't checking unstable code.
I went through all this and frankly I do not see single thing in centralized SCMs which is real prerequisite for corporations. Especially in corporations, where wrapper scripts are routinely used instead of raw tools. With git you can easily emulate centralized repository - and even more.
As Tom Lord (GNU Arch author; one of the first DVCS) put it: centralized VCS treats its users like second class and gives full power only to few - VCS admins. With DVCS, everybody gets the same power.
With decentralized SCMs, workflow is different and more flexible: you have revision control available all the time independently of what the rest of the company is doing...
Though I see your point now - no more coffee breaks due to server downtimes or lengthy checkouts or check-in ban (due to maintenance or reorganization). Yes, I agree with you completely now. Git is harmful to the corporate culture as a whole by eradicating its very foundation: coffee breaks. [/saracasm]
OMG, this was like eternity ago so I have forgotten. And the special layer to allow file systems to span multiple flashes (forgot the name).
Though ggp was trying to make a different point and I have forgotten to spell out my counter-point clearly: with 2.6, where you have more drivers and support for more boards/modules, you are not dependent on single hardware vendor. In mass markets, this is actually huge problem because over time, price for components (CPUs, SoCs, etc) actually goes up. Price curve starts at some high point (initial release, initial price) then relatively quickly goes down (as order volume increases) and then after some time starts slowly going up (as producers switch production to new components). If you plan to market your product for longer than ~5 years, to maintain low price, you either need to buy all components in advance or plan migration to new components after couple of years.
Slashdot Mirror
I didn't participate in such transitions, but one of my past employers did such migration already in OO.o 1.x times.
They have employed rather pragmatical approach and made (partial) migration in several phases. At first they mandated that all employees have OOo installed. Then whole R&D (and all of internal documentation) migrated to OO.o. That was rather painful yet rewarding. Then those who didn't need M$O ditched it. At the end of migration we had most of personnel using OO.o (rather successfully; it's when I joined the company) - only of sales (minority in engineering company) and test department were using simultaneously OO.o and M$O.
I'd rate OO.o for technical purposes higher than M$O since many features in former are implemented much simpler than their counterparts in M$O. Comparing old documentation M$O template with newer OO.o template I found that OO.o template was missing all the black magic people had to employ to make derived M$O documents easy to edit. OO.o's outlines alone were saving lots of time. Export to PDF was beautifully solving problem of communication with business partners.
All in all, I'd say, that using OO.o internally is pretty easy. Yet company has to be ready to have also number of M$O installations to be able to read/edit documents from partners. Hinting your partners that you are using internally OO.o and PDF/SWX/ODF are preferred formats might lead to some nice surprises: many companies at least pilot OO.o internally and pretty happy to send you documents in your preferred format.
And piece of advise: do NOT mix OO.o and M$O documents: binary .DOC format compatibility is all but myth. Implement OO.o where you can clearly draw a line between internal confidential documents and external/public documents.
Nothing directly related to RTFA. The reporter goes into excuses that he never heard of the Linux thing but since he is now enlightened by results of Google search, he really eager to learn about the Windows alternative.
The point of RTFA is not that Ubuntu is hard to use.
But that she skipped 5 months of school because she couldn't get Windows on it. Show at 11.
Ironically I know such people. Also I know well their reaction to problems with technology. In fact it is very predictable: they immediately call me.
I can't imagine that somebody lives in a place where there are no knowledgeable about technology people. If not to show how to use Ubuntu - but at least to help buy/install Windows. And with modern primitive (simpler than "simple") installation procedure of Windows you do not need to have any slightest clue about computers or OSs.
Anyway I look at the story conclusion is the same: she simply wanted to skip classes and looked for excuse.
It's a fake.
Actually I'm surprised that no M$ conspiracy theories were yet thrown in.
What is actually plausible: some M$ partner (e.g. same guys who supplies M$Windows/Office to her school) might wanted to FUD about Linux and just inflamed the story.
VirtualBox is slightly easier to install under Linux. And many distros have it already in repos.
Not as powerful as VMware, but less buggy.
You are underestimating her.
Be the girl airhead, she'd likely have a boyfriend who could have helped her to configure the lappy as she wished.
My first impression is that the girl wanted to skip classes and was just looking for excuse. And she found.
OpenVMS had both "impersonation" and "capabilities" (or "privileges") (See here). Where from they have actually came to WinNT.
Capabilities might be hard to spot, because in *nix universe (of which VMS is distant relative) they are bound to access to special files (normally under /dev in *nix and magic file names in VMS). By defining who has access to the special files, you define their capabilities.
I'm not a VMS historian so I cannot tell when the features went into the OS, yet AFAIK most of VMS development and core feature were stabilized by mid 80s. E.g. ACLs in VMS apparently appeared in 1984. Probably googling for "vms history" would bring more info. (Name change to "OpenVMS" happened in 1991.)
Other systems are also designed to protect system files from being modified by an application (say, a virus), but IPAT's patent goes one step beyond that, with a system that can prevent programs from modifying a user's files.
The "one step beyond that" part what is called "impersonation," when program works in context of a user. Impersonation is word from WinNT universe, though setuid is pretty much the same thing.
It's needless to talk about prior art. There are piles of it.
Oooo.. dangerous thinking. The complete lack of administrative overhead seems like a great panacea.. until you realise that you are essentially side-stepping any corporate data retention policy, side-stepping the benefits of corporate IT support and data protection policies, and increasing risk of partial data loss.
Load of bullocks. I'm working in corporations for past 5 years and yet to see any "benefits of corporate IT support." Corporate IT is generally some bunch of management-ass-lickers. They do not care about mere mortals developers.
As to retention policy and data protection, for past 4(?) years, my $HOME is always and completely backed up - and that's includes all my repos. In fact it is volume over NFS mounted from huge NAS RAID.
Or are you suggesting that, via forced git pulls from every single developer to every single developer you are thus creating a redundancy strategy better than the typical corporate IT backup/disaster plans? ..
You are severely behind times. See above.
so how is it that you are going to force all developers to do a git pull, or at least a push to some central machine on a regular basis without actually implementing *some* sort of IT-supported machinery?
When developer gets assignment (e.g. implement feature), he is also responsible for delivering on the assignment.
In CVS/etc it is check-in to global repository.
In Git this is push into global repository.
Difference? None.
Well, in fact there is one. In CVS/etc developer is responsible for integration of feature with rest of the system. If he wasn't bright enough and f***ed up rest of the system in the process - whole R&D is f***ed up. In Git, "push" remains local to the "global repository" and if somebody broke something, one can always review and reject the pushed changeset - even before anybody can pull it. Or even if you cloned the global repository, you still can remove the changeset locally. In Git there is very little overhead of maintaining repos which work only as staging area: where to others can push and where you (as e.g. release master or tester) can compile/test the changes. After changeset was cleared by release/test teams it can be pushed further into real global repository, where it would be visible by others.
Check that out - "Integration Manager Workflow". This is pretty much ideal workflow, which in past I have seen people numerous times tried to implement using centralized systems. And before DVCS I have seen only one solution which can be called "working."
Company can't fire people left and right. Because it's Germany.
In past my employer tried to "restructure" the company, yet some slackers - who were fired with the premise that their department isn't needed anymore - sued employer and got their positions back.
But also, from my experience even with most competent R&Ds is that you always have some people who "do not get it."
"Backbone" of R&D often are some spineless bunch of people living on payroll and living solely for the payroll. They have no opinions, they have no ideas. You can only set rules and give them assignment. Very manageable bunch, yet in the end - unmotivated and incompetent. And company-wide deployed tools are always selected looking back at the "backbone". I call it "backbone," because management see that as "backbone". Competent people who have opinion often are quite unmanageable (e.g. me). Managers do not like people like I am - yet they depend on us: because we give ideas to move product (and company) forward.
And then we come to a paradox. Company selects some stupid tool - because its level fits to average level of competence in R&D - and they tell me that since me is smart as I'm, I could figure my way around. And generally I do.
Like it is now with ClearCase in my company. From all CVS clones I worked before, CC is probably one of the best. Yet, it is a CVS in its heart. But I'm already (slowly) implementing some DVCS-like features. I already can "push" patch into branch (provided that there are no merge conflicts).
If you're talking about "cleartool update" and hijacking files, then you're using snapshot views. Ungh. They suck. Stick with dynamic views, and get your winkins to work, which usually means major makefile hackage. It is worth it.
Unfortunately, our main project is very large and when lots of people work with dynamic views, CC server simply dies under load. That was already tried right after CC deployment.
That said, I'm different company now and going through a git vs. subversion selection process. For some reason I can't get motivated by subversion. Git seems like a whole lot more fun. Not a very scientific or profession attitude, but that is also the reason I first switched to perl oh so many years ago.
If your company needs good Windows support - then you have to go with SVN or Hg (Mercurial) as only usable options. Git as *nix tool in its heart not very good on Windows. Folks with "msysgit" try to bring the power of Git to Windows and from comments I can judge that it mostly works, yet you shouldn't expect SVN level of integration with Windows out of it.
On other side, if development happens exclusively under *nix, then Git (or Hg) is really great tool. Especially if compared to SVN.
Unfortunately, I have experience only with SVN. Several of my past employers use it without major problems. I use Git for all of my pet hobby projects and pretty happy with it. I'm no novice to DVCS and I have used before Arch and Darcs. Darcs is very simple and Arch is very very powerful (and complicated). Git is good compromise between the two: simple things in Git are very simple but some complicated things are darn complicated. (Though I'm still missing Arch's archive system, which allowed to (in a way) partition version information so that size of currently used repository stays within some sane limits.)
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.
It may be that a centralized VCS like svn may be a better option.
I cannot conceive of a scenario where this is true.
You need to work shortly in some large corporate R&D. Average level of corporate developer is quite low. You wouldn't want to give all the power of Git (or any other DVCS) to them because quite quickly it would turn into total mess.
Also, I have seen that some not very bright developers are always on look out for features to abuse. E.g. I have colleague who always compiles whole tree (that takes about 2 hours). Whenever anybody ask him what he did on any particular day, he normally says "oh, some flags were set not right so I had to recompile." Adding here "oh I messed up my tree and had to clone again" wouldn't help the situation.
In corporations, you have not choice but to limit what developers can do with their time. Unfortunately in large R&Ds you always have to align on lowest competence level.
Although hard to mess up the remote copy, messing up your local copy was much easier.
Can't find the quote from Tom Lord (GNU Arch (tla) author, one of the first DVCS), but he was saying something like: in centralized systems, only admins have full power of the versioning, normal users are treated like economy class.
After migration from centralized system to decentralized, one has to stop for a moment and realize that now everything can be done, everything is possible: there are no more big brother behind your back. This is great power and at the same time great responsibility. But thanks to the fact that you ruin only your local sandbox, that "great responsibility" bit can be easily ignored, leaving you only with "great power."
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.
Can't tell for SVN/Perforce, but I can tell for some other centralized systems. It is not so very clear what you are doing there either. Most centralized systems have heaps of scripts running server-side which might actually recast any command you are issuing into something completely different.
But as I have mentioned above, in centralized systems you can do much much less with your repository. Decentralized systems provide much more functionality and that gives rise to the confusion. It's only natural.
To me personally, main advantage of systems like Git or HG or Arch is that there is literally no administrative overhead. (Well, truth to be told, Arch has some.) If you have well organized development with many people involved, then the overhead of setting up and maintaining centralized repository isn't that great. But in my case of lone hobby developer, set up of SVN server, integration with Apache - are all just time wasters. I have started reading SVN documentation but it was already too late in SVN life cycle and documentation became very very fat. But with Git all I need to do to start new project is "mkdir fancy-project; cd !$; git init" and then just move files over. And, most importantly, performing backup is as easy as "git push".
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".
[...] then I think it will be hard to keep developers interested in doing kernel work - it will seem too much like real work, but unpaid.
Well, it was well advertised before that kernels have little to no interesting challenges - all problems are well known and 30+ years of research is easily available.
Frankly, I'm pretty happy that Linux reached such level of stability. Perl is in the same state: after 5th release, there were very very few major changes. But why to changing anything if it works well already??
Also, stabilization of core Linux means that developers have a chance to rethink many design decisions and correct them. Before, Linux was like in haze to catch up to the level of many commercial OSs, with much much longer histories. Now it firmly stands above most if not all kernels, though as OS (GNU/Linux, distro, etc) there is lots of work ahead - work which can be done now because there is such good stable foundation.
Looking back, I think change of development model during 2.6 series was genius decision. Linux had grown up and doesn't need pampers^W version changed every year anymore.
There is a large upfront cost of switching.
In 3rd world people are saving by switching, since Linux can be customized to run on less resources. E.g. Linux Terminal Server is much much resource savvy compared to Windows Terminal Server.
And a lot of people will not be happy that they can't do X like they did before.
I'm pretty sure that Vietnam has its own ISVs. And the move - is the huge investment into ISV sector. For government it's a huge win too: more taxes.
And if they need support on some feature you can't intimate a US Open Source Developer by saying you are from the government.
Do not be silly. US != World. Local ISVs can do it and there are lots of Linux consultancies around of world. Asia is not that backward as many CNN/FoxNews watchers might think.
This is huge chance for local business to cash in - in long term. If gov't is serious, I'm sure they wouldn't let the chance to slip.
At least with Microsoft and you are a big customer they will bend over backwards to help you.
That's big lie. They will "bend over backward" if you have enough money to pay them for that. Otherwise you are on your own.
M$ can and does something on their own - but they rarely listen to feedback. Generally, in M$ ecosystem, burden of backward compatibility is on integrators and ISVs. My friend worked for such company in past implementing features (normally using ActiveX) from new M$ products for older M$ products (and vise versa) as well as smoothing integration with 3rd party software. Imagine: huge business built around solving problems created entirely by M$ development strategy.
I do no think that has to do anything with Linux as much as with Micro-Soft putting more pressure on 3rd world governments to curb piracy. It is hard to put pressure on commercial entities there, but government (vulnerable to external political/economical influence) is always easy target.
IIRC, Vietnam tops the list of most pirating nations. What is not surprising with monthly wages in range of $50-100. Windows even at $20 is still too expensive.
I've never had a problem that ubuntuforums.org didn't have the answer to.
To ask a question is also a skill which requires some knowledge. Or how old saying goes "a good question contains half of the response."
I haven't read the particular book, yet generally such books a great starting point - a stepping stone which helps to start asking questions.
Properly-managed centralized version control allows anyone to check in at any time.
It doesn't need to be "properly-managed." You can actually do that in SVN already (modulo merging).
You simply have to forget about performance and start getting used to coffee breaks. That's from my personal experience.
And worst case performance of SVN can be really really bad. Colleague of mine updated important headers - and bunch of related files. Everybody got e-mail in the morning and started update. After waiting 30 minutes for svn to finish (normally took ~5minutes) I decided to make my lunch break earlier. Real life story.
Branching in SVN also works. But merges - especially on large project are really nightmare. My past employer actually set sort of record: check-ins were prohibited for two weeks straight so that people can actually check-in fixed results of merge. That's reality of how it works - and you can't make it better in centralized system. Unless of course you can get one of those rare magic wands for your "management."
Properly-written centralized version control software allows anyone to save checkpoints at any time without requiring access to the server.
That's nonsense. The whole point of centralized system that all actions are recorded at central location. (So that they e.g. can be backed up centrally.)
You apparently have no slightest idea what it takes to create your own tag or branch in centralized system - and what kind of performance impact it has on *every user*. But even if we leave performance issue aside, with R&D >50 people you have to be ready for very very serious clashes of tag/branch names. They are all global because they are all in central repository, you know.
That's why pretty much every sane company using centralized SCM have strict rules that only very very few people can create tags/branches.
Centralized systems do not scale on user number. That's pretty much established fact. There is no point to argue on that. But it's not that you had any arguments to begin with (idealistic crap doesn't count). Frankly, I'm also not good in argument department: it's just I worked with CVS/SVN/friends more than 7 years now.
Unless the revision control system's performance is dreadful I think that all files should be in revision control.
I have to agree. Or rephrasing old saying: a not-checked-in file doesn't exist. (Original by my colleague is "a not-checked-in source code doesn't exist" after several weeks of nightmares trying to reproduce past test case.) Referring to the fact that if file is not under revision control, then you do not have any control over the file.
Or in other words: if you put blobs into SCM, forget about performance.
There is no - per definition - good VCS for blobs. That's all I wanted to say.
SVN is suited for it better than Git, yet SVN also performs in some conditions quite bad.
Subversion is centralised, based on a single server for the repository, and therefore suitable for corporate use.
What is actually big big lie repeated over and over again. So most think it is true.
Just recall all the pains of branching - and merging (and loosing all revision history from the branch).
Or worse - having no revision control for weeks or months. Since you can't checking unstable code.
I went through all this and frankly I do not see single thing in centralized SCMs which is real prerequisite for corporations. Especially in corporations, where wrapper scripts are routinely used instead of raw tools. With git you can easily emulate centralized repository - and even more.
As Tom Lord (GNU Arch author; one of the first DVCS) put it: centralized VCS treats its users like second class and gives full power only to few - VCS admins. With DVCS, everybody gets the same power.
With decentralized SCMs, workflow is different and more flexible: you have revision control available all the time independently of what the rest of the company is doing...
Though I see your point now - no more coffee breaks due to server downtimes or lengthy checkouts or check-in ban (due to maintenance or reorganization). Yes, I agree with you completely now. Git is harmful to the corporate culture as a whole by eradicating its very foundation: coffee breaks. [/saracasm]
eXecute-In-Place [...]
initramfs and tmpfs [...]
OMG, this was like eternity ago so I have forgotten. And the special layer to allow file systems to span multiple flashes (forgot the name).
Though ggp was trying to make a different point and I have forgotten to spell out my counter-point clearly: with 2.6, where you have more drivers and support for more boards/modules, you are not dependent on single hardware vendor. In mass markets, this is actually huge problem because over time, price for components (CPUs, SoCs, etc) actually goes up. Price curve starts at some high point (initial release, initial price) then relatively quickly goes down (as order volume increases) and then after some time starts slowly going up (as producers switch production to new components). If you plan to market your product for longer than ~5 years, to maintain low price, you either need to buy all components in advance or plan migration to new components after couple of years.