I'm citing things that I have PERSONALLY encountered when using file hierarchies that someone else has defined before I came along. It has become *so* common for me to bump up against Windows MAX_PATH limit that I keep a "bare drive" *just* so I can copy checked out files to "\" instead of into a path prefix of: "\Sources\ClientA\ProjectX\revY". Even then, I often have to check something out on another machine, walk *down* to a lower portion of the hierarchy (to skip over some shared prefix portion -- like "usr/src/sys/arch/i386/stand/netboot") and build a tarball *there* that I can then export to the "local" machine. Putting *more* stuff in the path only makes this more common!
*You* work in a world where *you* control (or can influence) the way things are done. *I* have to tolerate disparate systems designed by a variety of different people with their own notions of "Right". I have *no* desire to educate them on how *I* think they should run their businesses!Should I extol the virtues of OS #1 over OS #2? Of MRP system X over Y? Of spreadsheet program E over P?
Should I *force* them to use what *I* want (ha! the silence before the uncontrolled laughter would be deafening!)? "And what makes you think you're so much smarter than us? We booked $10B last quarter and have 10,000 employees. And you??"
You want a PutChar.c and a putchar.c in the same directory? OK, I'll have to pay particular attention to the messages emitted when I extract the archive on a windows machine as one of these will *not* be present in the sources that I work with, otherwise.
No, not "imagined" problems. Problems that have *bitten* me over the years due to having to work in such divers environments. So, I look for mechanisms that would *reduce* the number of these silly problems that "needlessly" crop up.
Just because the world I work in doesn't conform to some idealized version that *you* think ALL should (because they seem to make sense to YOUR worldview) doesn't mean you should impune my technical abilities. Instead of dismissing my comments, *think* about them and how *you* would handle them GIVEN THAT YOU'RE NOT OMNIPOTENT AND CAN'T FORCE THE PEOPLE WHO SIGN YOUR PAYCHECK TO DO YOUR "BIDDING". Simply telling people "you should use ____" or "you should use Linux" or ... indicates an extreme intolerance for the conditions which others work in.
Or, a belief that you've somehow got a monopoly on "Right" (does God talk to you?)
In any engineering undertaking, there is *never* "The" right solution. You are always picking between "less wrong" solutions. The same is true of most human endeavors. You might disdain Adobe Reader as it is full of security holes. Preferring, instead, some other product and forgoing support for some of the features that Reader provides. Someone else might come up with a "solution" that simply puts the security issue onto the backs of their existing IT department!
E.g., *I* choose not to waste time with the endless "security updates" that plague EVERY OS IN USE TODAY -- as well as many applications thereon. My solution is simply to not allow my development machines to talk to the outside world! The "cost", to me (personally -- since I am the guy who would have to implement all those updates and patrol for attacks and breaches) is "you have to walk into the dining room to browse the web or send email". Feh. Note that it takes no longer to *perform* those activities -- just the time to walk 50 ft! I probably save a hundred hours (or more) each year by doing this.
Before desktop inet access was so prevalent, PC manufacturers tried other approaches to keep machines from "infection" -- disabling boots from removable media (USB, floopy, CD), etc. There's no
*one* solution -- instead, a variety of solutions each having different cost-benefit complexions!(actually, keyword expansion *does* solve those problems. It allows the absolute path of the checked out item to be recorded *in* the item. Along with it's revision level. I.e., drop that "bag of files (screws)" on the floor and *I* can put them all back where they belong. Remove those keywords or disrupt the positions of files within *your* checked out hierarchy and you're *screwed*)
Make sure you NEVER LEAVE your current employer. You'd really have a tough time dealing with *imposed* file naming conventions, variable naming conventions, coding styles, testing methodologies, dress codes, etc. that didn't, by chance, coincide with your
*notion* of what they should be! :>
Like the name of the *artist* ($Author$)? How they fit into their "container"/album ($Path$)?
So none of the *100's* of library files typically used in a project have any "freestanding merit"? They only make sense in the context of a "project"? So, obviously, all of the commentary
*in* those files relates directly to *that* project, right?/* strlen() -- find the length of ASCIIZ strings used in ProjectX */ /* printf() -- print messsages on the ProjectX console */
Yes, we should move the *comments* out of these files, as well! Utterly irrelevant and get in the way of finding the actual source code! You should retrieve them -- and the motivations for each decision embodied in the implementation -- from a separate design document! :-/
I want everything pertinent to an algorithm to be *with* the algorithm. E.g., my comments will indicate test cases that specific code stanzas are designed to safeguard against. Or, notes referencing bug reports that a particular modification is designed to address.
My 9-track device driver begins with 5 pages of commentary explaining the terminology pertinent to 9-track tape (transport) technology. Without it, a maintainer would be largely clueless to understand why things are done the way they are. Does this belong in a *separate* document that is likely to get misplaced? Or, that the maintainer might not even be *aware* of??
Because it puts the information *in*/with the object to which it pertains! Once I pull sources onto my laptop, I don't *have* access to the client's repository. You're advocating I checkout the source(s). Then, query the CVS for all *related* information (revision history, log messages, etc.) and store that somewhere ALONGSIDE the files in question (this is somehow better than storing it *in* the files in question? How? Because it takes *less* disk space? Because it is easier to open *two* files in an editor instead of two *views* into the same file? Because it is easier to keep those two files *together* than it would be to have them COMBINED into *one*??)
I guess it never occurred to you to rename one or both of them? Ah, but then you'd have to give each of them names like: bob_release_rev2_add.c tony_experimental_rev2.1_add.c I, OTOH, give them names like x.c and y.c -- and rely on the $Id$ keyword to unambiguously tell me *everything* I need to know about their real names, positions in the source hierarchy, release/experimental status, revision number, author, etc. ("Hmmm, Tony said he added support for blue weenies -- but I don't see it here, anywhere... Ah, this must be *Tom's* file??")
There is no *cost* to navigating to that "other" directory to open the file alongside the "first" file? You just invoke the file|open dialog and click to your heart's content until you get *to* the required directory? Or, cut and paste it on the command line??
You're extra diligent and never accidentally *save* to one of those ("touching" it in the process)?
I always create a "work" subdirectory wherever I am. In it, I can do anything I want -- intentionally or UNintentionally -- to any of the contents. So, if I happen to accidentally overwrite the "original" of a file, I can *see* that I have done this and fetch a new copy from the repository *or* the checked out directory elsewhere. I never run the risk of altering something that I shouldn't without being aware of that.
It also makes it really easy to access the objects that I need -- they're all in one place: $VISUAL *.c *.h
And, I can feel free to: find / -name "work" -type d -exec rm -r {} \; at any time!
But that assumes you have that facility *on* all of those machines! When I write code, all I need is an editor. Not an IDE. Not a VCS. Not a compiler. An *editor*. I can use *your* laptop to write *my* code. I can use notepad on a client's secretary's desktop machine.
I can maintain code written 20 years ago -- while Hg was just a gleam in some teenager's eye!
I'm not constrained to only being able to work on a project when I have emacs available (authoring), gcc (compiling) and gdb (debugging), cvs (versioning), emulation tools (emulating), desktop publishing tools (spec review), schematic capture (reviewing the circuit design), PCB layout (reviewing the board), etc.
They are all things that I *might* need. But, chances are, I *won't* need any of them -- especially if I'm just "writing code"! And, by far, that represents the majority of the time I spend on a project! Your *brain* and hands are the bottleneck in any project!
Perhaps you like to "tinker" while writing: let's see if this code fragment does what I *think* it does (should do). I don't. I spend an inordinate amount of time *designing* my projects. Designing the algorithms. Formally specifying *how* those algorithms will work. Implementing those algorithms as specified. *Then*, looking to see that they actually meet the specifications I've set out for them.
The same is true of my hardware designs. I can usually bring up a new board in two days -- almost regardless of complexity! It boils down to verifying the components on the board are operational and the board was fabbed correctly. The design "worked" -- BEFORE it was committed to foil!
Have you tried to *imagine* the scope of that task? Look at *your* repositori(es). Look at the amount of "source" you are managing (however you define "source") in terms of "compiled bytes". Then, look at how much the *raw* source takes up. And how many managed objects are involved. Each object is an opportunity for that "automated migration" to screw up. And, chances are, you won't realize this until you go to check out one of those objects in your NEW VCS at some future date (if you're going to keep the old one around, then why not just keep *using* it??).
I took a *quick* look at some of my repositories, here. The "legacy projects" one is only ~40G -- 152,957 objects (there are some sizable objects in there). My "current" repository has ~3000 objects filling 65MB for just the RDBMS sources (not counting any of the data I've got residing in the active instances deployed here). My "standard libraries" are about 100MB and contain ~12000 objects. The sources for the basic tools that I use (i.e., to maintain my work environment) represent another 100000 objects, etc. (note that this doesn't include executables for which I have *no* sources!) And, the OS itself is yet *another* 100000 objects (again, ignoring executables). etc.
And I haven't yet *touched* on "project files" (i.e., the above can apply to *any* project)! E.g., each build of my backup speech synthesizer (potentially) commits another ~100MB to that repository. Do this once or twice a day (this is EASY to do when you're dealing with fine tweeks to a ruleset that you are trying to keep VERY small!) and your repository grows by 1GB/week. Yet, the *executable* for that synthesizer runs in a ~30K footprint!
OTOH, each time I commit a snapshot of the RDBMS contents, I'm EASILY in store for 100MB "hit" (there are less resource intensive ways of doing this -- but, none that will be portable across versions of the RDBMS itself!).
No, I have no desire to put this all at risk. As I tell friends who harp on me to upgrade my OS, tools, etc.: "Ignoring, for the moment, the cost that *I* (personally) will incur for taking on that activity (remember, "my boss" doesn't cover the cost of this exercise!), what will I *gain* by doing it THAT I DON'T ALREADY HAVE?" This is usually where the conversation ENDS.
Work a 9-to-5 and its easy to see pushing for these sorts of changes. You (hopefully) benefit. And, someone else bears the *cost*! OTOH, if the time and expense to do it comes out of *your* budget (*pocket*), you tend to develop a different set of criteria for which battles are worth fighting. Folks tend to be really quick to say "it WILL work" -- but really hesitant to put
*their* money on the line. Even worse, put their *time* on the line! :>"How much (man-hours) effort is involved? OK, and what's your burdened rate of pay? So, if I give you $X, you would have no problem signing a contract to provide that're service to me in that timeframe, right? Ah, I see you're hedging a bit on the money. And *timeframe*. So, what degree of uncertainty is that reflecting on your part??"
This is the approach I advocate to folks looking for canned, COTS "solutions" to "their problem" -- whether it is an accounting system, an MRP package, a time-tracking tool, etc. It's always amazing how quickly the sales droids go on the defensive when confronted thusly. A minute earlier, they were confidently predicting how effortlessly it would fit your needs. Then, suddenly, they weren't quite as certain! :-/
"Oh, we have staff that can help you with this transition (at $300/hr for an indefinite time frame)."
Advice: If you want a guaranteed job, get involved in one of these (boring) neverending "porting efforts" at a customer with (very) deep pockets! They won't finish porting to version X before version *Y* is released. Then, will chase version Y until long after version Z! :-/
(IMO, there are more interesting ways to spend that 1/3 of my life, thankyouverymuch!)
I have no desire to adopt yet another VCS. The logical conclusion is to wait indefinitely for the "right" system to come along. git, cvs, hg, svn, etc. are just stepping stones on a continuum. Adopt any of them and you need to be prepared to ABANDON them when the next great thing comes along. Etcetera.
I approach my tools differently. I find something that works, for me, and stick with it -- until it *doesn't* work. Like a carpenter, I have no desire to keep mucking with hammers. If I *need* a nail gun (e.g., to shoot anchors into a concrete floor/wall), then I'll use a nail gun. If I *need* a bodywork hammer to shape a fender, then I'll use one. But, if I'm framing a house, I only need *one* claw hammer to do the job. Even though the one with the fibreglass handle might be a bit lighter; or, the shot-filled handle a bit more *effective*...
If I don't want to *buy* a shot-filled, fiberglass hammer, then maybe I'll just "no-bid" that job! (?)