• Fran (unregistered) in reply to RH

    ROFL - this is the first tiem I've ever read The Daily WTF, and I laughed my head off!!!!

     Here's the REALLy funny part....

     When I joined my current company - THEY WERE DOING THE SAME EXACT THING!  Seriously. 

    We didn't have Merge days.  We had MERGE WEEKS.  Image, if you will, 4 months worth of development, done in .NET, by various groups from various locations, and all with few of any requirement.

     So - now we need to go to QA.  This is a major event.  The entire company stops everything its doing.  Development as a whole is drafted to complete the horrendous task of merging hundred of pieces of code to the main branch.  The rest of the company stands ready to begn the equally impossible task of testing whatever the ultimate outcome of Merge Week will be.

     

    And then...after a week of merging and another week of getting it to install and run.....

    Defect fixes were made directly into QA and then checked -in to the next branch of the version control.  Yes, you did read that correctly.

    When I came here the first thing I did was scrap the entire tool and implement a version control system THAT DOESN'T USE BRANCHING.  (I know - its a rough concept - give it a minute and just let the words sink in slowly....)

    We use AccuRev now and we LOVE it.  No branching, no surprises, no code freezes..I haven't seen a branch in almost two years and I hope I never do again!

    Best of luck to all you mergers.  You have my sympathy :)

    Fran - x-BIG TECH scm

  • Anonymous (unregistered) in reply to Bob Janova

    Bob Janova:
    You may not technically have to coordinate changing oft-referenced modules while using decent source code management (or even SourceSafe :P), but if you're going to change the interface to them or the way they work, you're going to break a lot of code when you check it back in. You really ought to have a little discussion meeting with the other devs (or other project leaders, if your company is too big to do everything with everybody) to (a) make sure your proposed change isn't a WTF, and (b) make sure they know what's going to break and why.

    One of the morals I see in a lot of WTFs is that you can't use software to fix organizational communication issues.
     

  • Mark (unregistered) in reply to cavemanf16

    I've used CVS, SVN, PVCS, Source (Un)safe, TFS and tried several others and I have to say SVN is by far the best and TFS is by far the worst, yes even worse the source safe.

  • (cs) in reply to BtM

    Anonymous:
    I've used ClearCase, CMVC, CVS, and PVCS. Given those choices, I'll go with ClearCase. 

    You should try perforce (www.perforce.com) - once you use P4, you'll realize how fundamentally broken most other systems are.

    Personally, I have an (admittedly minor) life goal to never use anything else - I've actually quit jobs because I couldn't stand having 25-50% of my day wasted by a broken source-control system (e.g. SourceUnSafe), and I couldn't convince The Powers That Be to look seriously at the alternatives.

  • (cs) in reply to Fran
    Anonymous:

    ROFL - this is the first tiem I've ever read The Daily WTF, and I laughed my head off!!!!

     Here's the REALLy funny part....

     When I joined my current company - THEY WERE DOING THE SAME EXACT THING!  Seriously. 

    We didn't have Merge days.  We had MERGE WEEKS.  Image, if you will, 4 months worth of development, done in .NET, by various groups from various locations, and all with few of any requirement.

     So - now we need to go to QA.  This is a major event.  The entire company stops everything its doing.  Development as a whole is drafted to complete the horrendous task of merging hundred of pieces of code to the main branch.  The rest of the company stands ready to begn the equally impossible task of testing whatever the ultimate outcome of Merge Week will be.

     

    And then...after a week of merging and another week of getting it to install and run.....

    Defect fixes were made directly into QA and then checked -in to the next branch of the version control.  Yes, you did read that correctly.

    When I came here the first thing I did was scrap the entire tool and implement a version control system THAT DOESN'T USE BRANCHING.  (I know - its a rough concept - give it a minute and just let the words sink in slowly....)

    We use AccuRev now and we LOVE it.  No branching, no surprises, no code freezes..I haven't seen a branch in almost two years and I hope I never do again!

    Best of luck to all you mergers.  You have my sympathy :)

    Fran - x-BIG TECH scm

    You see, if this is true, this is a sad thing, because branches have their uses and are extremely powerful, but since you've been burned and deeply scarred by misuses of branches you've decided to completely shut them out and stop using them.

    You'll probably never know what you're missing, and you'll probably never question the useful use of branches, because to you they've pretty much become "pure evil".

    Such a waste.

  • lostlogic (unregistered) in reply to masklinn
    masklinn:
    Anonymous:

    ROFL - this is the first tiem I've ever read The Daily WTF, and I laughed my head off!!!!

     Here's the REALLy funny part....

     When I joined my current company - THEY WERE DOING THE SAME EXACT THING!  Seriously. 

    We didn't have Merge days.  We had MERGE WEEKS.  Image, if you will, 4 months worth of development, done in .NET, by various groups from various locations, and all with few of any requirement.

     So - now we need to go to QA.  This is a major event.  The entire company stops everything its doing.  Development as a whole is drafted to complete the horrendous task of merging hundred of pieces of code to the main branch.  The rest of the company stands ready to begn the equally impossible task of testing whatever the ultimate outcome of Merge Week will be.

     

    And then...after a week of merging and another week of getting it to install and run.....

    Defect fixes were made directly into QA and then checked -in to the next branch of the version control.  Yes, you did read that correctly.

    When I came here the first thing I did was scrap the entire tool and implement a version control system THAT DOESN'T USE BRANCHING.  (I know - its a rough concept - give it a minute and just let the words sink in slowly....)

    We use AccuRev now and we LOVE it.  No branching, no surprises, no code freezes..I haven't seen a branch in almost two years and I hope I never do again!

    Best of luck to all you mergers.  You have my sympathy :)

    Fran - x-BIG TECH scm

    You see, this is a sad thing, because branches have their uses and are extremely powerful, but since you've been burned and deeply scarred by misuses of branches you've decided to completely shut them out and stop using them.

    If anything, that's extremely sad.

    Accurev has streams... I'm not sure how these are any better than branches really, other than they automatically let changes from the 'head' flow into them rather than staying based on a fixed point in time like branches are, requiring frequent branch hops on long lived projects.

    Accurev may have a novel model for SCM, but it doesn't solve the problems of delayed integration, nor does it solve the problem of conflicts. For that matter, it makes conflicts worse, by causing a conflict any time a file is changed in 1 stream and its parent stream.  It also noteably has a horrendous command-line interface, and a single-point-of failure server design that puts the system in a _completely_ useless state if the server goes down.


     

  • (cs) in reply to lostlogic
    Anonymous:
    masklinn:
    Anonymous:

    ROFL - this is the first tiem I've ever read The Daily WTF, and I laughed my head off!!!!

     Here's the REALLy funny part....

     When I joined my current company - THEY WERE DOING THE SAME EXACT THING!  Seriously. 

    We didn't have Merge days.  We had MERGE WEEKS.  Image, if you will, 4 months worth of development, done in .NET, by various groups from various locations, and all with few of any requirement.

     So - now we need to go to QA.  This is a major event.  The entire company stops everything its doing.  Development as a whole is drafted to complete the horrendous task of merging hundred of pieces of code to the main branch.  The rest of the company stands ready to begn the equally impossible task of testing whatever the ultimate outcome of Merge Week will be.

     

    And then...after a week of merging and another week of getting it to install and run.....

    Defect fixes were made directly into QA and then checked -in to the next branch of the version control.  Yes, you did read that correctly.

    When I came here the first thing I did was scrap the entire tool and implement a version control system THAT DOESN'T USE BRANCHING.  (I know - its a rough concept - give it a minute and just let the words sink in slowly....)

    We use AccuRev now and we LOVE it.  No branching, no surprises, no code freezes..I haven't seen a branch in almost two years and I hope I never do again!

    Best of luck to all you mergers.  You have my sympathy :)

    Fran - x-BIG TECH scm

    You see, this is a sad thing, because branches have their uses and are extremely powerful, but since you've been burned and deeply scarred by misuses of branches you've decided to completely shut them out and stop using them.

    If anything, that's extremely sad.

    Accurev has streams... I'm not sure how these are any better than branches really, other than they automatically let changes from the 'head' flow into them rather than staying based on a fixed point in time like branches are, requiring frequent branch hops on long lived projects.

    Accurev may have a novel model for SCM, but it doesn't solve the problems of delayed integration, nor does it solve the problem of conflicts. For that matter, it makes conflicts worse, by causing a conflict any time a file is changed in 1 stream and its parent stream.  It also noteably has a horrendous command-line interface, and a single-point-of failure server design that puts the system in a _completely_ useless state if the server goes down.


     

    I don't know accurev at all so I'll thank you for these informations, but re-reading the original post on the subject, I guess that the OP doesn't know about these "streams", or at least doesn't use them. In fact, he could use pretty much any SCM and just not use branches.

    At a higher level, the part that I was finding fairly sad is that he's locked out any branch-like feature in a zone marked "DO NOT USE" in big, bold, red letters, and that's the big issue to me, not the fact that his SCM of choice does have branches even though he doesn't know it.

  • Hill (unregistered) in reply to ParkinT

    RE: ParkinT's .sig.

     

    My favorite is actually: "The Complete Idiot's Guide To Poor Self-Concept".

     It includes a DVD and a mirror.

    Cheers!
    Hill

     

  • Qr (unregistered) in reply to Ether
    Anonymous:

    <blockquote>

    I can almost hear all of you source control experts cringing, thinking that's the exact opposite of how it should be done: everyone should work in the trunk and branches should be created at the time of incremental releases.

    </blockquote>

     

    Actually, no.  It *is* a good thing for separate projects to work in separate branches.  The only WTF is that there is an ordained "Merge Day" to bring everything back together, when in fact one should merge back up to the parent branch *as soon* as the changes made in that branch are tested and working.  And one should regularly copy down changes others have made to the parent (as soon as possible, without disrupting the work you are doing), so as to bring in new API changes or other changes that will affect the code you are changing.

     

    It's amazing how most people do branching totally wrong.  It's not actually that hard when you think about the problem you need to solve -- changing code without others' changes screwing you up, or your changes screwing other people up. 

    Shouldn't it be the opposite - always work on HEAD, tag releases, branch if needed? Branch for larger change - sure, but constantly - WTF?

  • (cs) in reply to trav
    Anonymous:

    It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.

     A clear case of finding a comple/enterprisey solution for a simple product.

     Clever, but I think you're wrong. I'm guessing Big Tech shares the "Big" with the nickname of a Fortune 50 company.

  • (cs) in reply to trav
    Anonymous:

    It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.

     A clear case of finding a comple/enterprisey solution for a simple product.

     Clever, but I think you're wrong. I'm guessing Big Tech shares the "Big" with the nickname of a Fortune 50 company.

  • Kanis (unregistered) in reply to savar
    savar:
    Anonymous:

    It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.

     A clear case of finding a comple/enterprisey solution for a simple product.

     Clever, but I think you're wrong. I'm guessing Big Tech shares the "Big" with the nickname of a Fortune 50 company.

    Would that be Big Blue, or Big Iron? :) 

  • Webzter (unregistered)

    We had a great problem like that when I first started at my employer... our group had five web sites to maintain with a separate repository for each (good). Each repository had 2-5 branches (good) (mainline, release [prod support], monthly enhancements, and one per active project). However, each branch then had a private branch per developer (ouch). We had a monthly merge day with a dedicated developer who just handled merges for all of the branches and builds. We had a semi-automated, single-threaded build environment.. it was a beautiful thing, it checked out the code and then built and deployed once per environment. One day was dedicated to merging. The next day was dedicated to merge cleanup and deployment.

    The commercial versioning system (with pessimistic locking) was replaced with CVS (CVSNT actually) and optimistic locking. The manual build job was replaced with AntHill/Ant/NAnt. The single-threaded deployment in-house tool was replaced with Robocopy. We got rid of the private branches and instituted a policy of team accountability for merging across branches and grabbing the other developer when a merge conflict hit (using Araxis Merge for conflict resolution).

    Good times... good times..

  • PseudoNoise (unregistered)

    I like measuring WTFs now by noting at which sentence I first make an involuntary exclamation.

     Today's was at the line: "They could now model their source control after their development model:..", to which I said, "Oh no!" aloud...
     

  • (cs) in reply to Qr

    Making a seperate copy of the source for a planned release is generally referred to as 'Forking', while 'Branching' is for seperate sets of source that changes are checked into.

     For example, "Doorways Horizon", and "Doorways Antler Server" share a common codebase, but the codebase 'forked' for the "Horizon" RTM releases. When a developer checks in a code change it has to specifically be tagged for which Fork(s) it's been approved for, but it still (generally) goes into the Branch for the team that developer is on, and migrates up towards the root, as each branch-level passes its testing. Once a change reaches a root, it is very quickly distributed toward the leaf nodes, so that any pending changes in another branch that would depend on it would be found before they migrate upward. 

     The very very important part of this, is that there is a continuous merge cycle. Each branch takes a turn to update the root, and with an outbound cycle after every check in turn. If something breaks, it's known exactly who checked in the breaking code. If the recent check-ins break your planned check-in, you have a chance to catch it before checking your stuff in. Instead of the system in todays WTF, which decribes a pig-pile of code all trying to integrate at once. I'd compare that system to a traffic light system on which all the lights show green or red at the same time.

  • (cs) in reply to cavemanf16
    Anonymous:

    Anonymous:
    I've used ClearCase, CMVC, CVS, and PVCS. Given those choices, I'll go with ClearCase. 

     

    What's wrong with using SVN? (Yes, I haven't liked CVS much, but SVN seems quite capable) 

    What part of "I've [only] used" and "Given these choices" was so difficult to grasp?

    Why all the arguing about whether this was Rational or IBM? They're the SAME COMPANY now, and it could just as easily have been either before the buyout. 

  • (cs)

    I contracted for a company once that had put their own shell around CVS.  The end result was a ui that worked just like (read: just as bad, and more often worse than) VSS.  It forced the 'checkout/checkin'' paradigm, spat out tons of noise in its output window when any action was ever taken (rendering the output useless), from its directory browser you couldn't tell which files on your machine were already under source control or not (you had to move the dialog out of the way to see which ones were already there), etc.  I never could understand why they built that horrendous contraption on top of it.

    To join in the "which is my favorite" fun, I've worked with ClearCase, PVCS, CVS, VSS, and PerForce.  Given my current company opts for the free-ness of CVS, and given that's the one I've worked with mostly, and it's got WinCVS and Eclipse to act as a ui, I'll go with CVS.

    A note on ClearCase....the few months I was working for a company that used ClearCase, I noticed they used branches out of the wazoo.  Must be part of the CC culture.

  • reptar (unregistered) in reply to suzilou

    Even more fun than using SourceSafe, is using SourceSafe remotely!  (yes, I know SourceGear have a front end for it, but better off using their Vault product if you want to have that Visual Studio integrated enterprisey look thing going).

     

    Still, SourceSafe is not the worst source control product I've ever used.  That prize goes to Borland TeamSource. 

  • Keith Wright (unregistered) in reply to Josh

    No, no, no...

     

    You do not branch in Source Safe under any circumstances if you value your life.  Doubly not if you are using Visual Studio integration.

  • Darin (unregistered) in reply to Fran
    Anonymous:

    We use AccuRev now and we LOVE it.  No branching, no surprises, no code freezes..I haven't seen a branch in almost two years and I hope I never do again!

    Sometimes you just have to have branches.  At least if things are done right.  Otherwise the only way to get bug fixes to existing customers is to have them always upgrade to the latest release.  I've been at companies that did things that way, and it was a mess.  Every customer tended to have a unique release, and release schedules were ad-hoc.

    Most places though have planned releases.  If a release comes out in 6 months, then the only sane way to get bug fixes to customers before then is to create a bug-fix branches for previous releases.  Even if the releases aren't planned, customers may not want to be forced to upgrade just to fix bugs.

    Software development just isn't a linear process.

  • Its a secret! (unregistered) in reply to savar
    savar:
    Anonymous:

    It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.

     A clear case of finding a comple/enterprisey solution for a simple product.

     Clever, but I think you're wrong. I'm guessing Big Tech shares the "Big" with the nickname of a Fortune 50 company.

     

    I am pretty sure the company he is referencing also has that word in its nickname.

    By now pretty much everyone has figured out who they are.

    My thought is that in instances like this when so many clues are given, they might as well give the company name in some form or another.

     

  • Martijn (unregistered) in reply to Ether

    Actually, no.  It *is* a good thing for separate projects to work in separate branches.  The only WTF is that there is an ordained "Merge Day" to bring everything back together, when in fact one should merge back up to the parent branch *as soon* as the changes made in that branch are tested and working.

    It would be a good thing if the separation was actually separating anything useful. As I understand it, these branches were meant to mirror the organizational structure or the company, not anything technical, like it should be. These branches were departments, not projects. I can only imagine multiple departments working on the same code (hence the need for a "Merge Day"), thus eliminating the posibility of any integration tests before this "Merge Day"; it's actually worse than having no branching source control at all.

  • TheLegend (unregistered) in reply to Who wants to know
    Anonymous:
    Anonymous:

    It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.

     A clear case of finding a comple/enterprisey solution for a simple product.

     

    Was the "clear case" reference INTENTIONAL?  Clearcase is a program of this kind!!!

     Steve

     

    Jeepers you're slow. 

  • The Big D (unregistered) in reply to TheLegend

    Don't FORGET that this is our FRIEND Steve! I THINK he LIKES to make SURE of things BEFORE he POSTS! And also lets us KNOW which POINTS of his post need PROPER EMPHASIS.

  • (cs) in reply to BitTwiddler

    BitTwiddler:

    You should try perforce (www.perforce.com) - once you use P4, you'll realize how fundamentally broken most other systems are.

    A lot of people keep saying that perforce is the mother and father (and possibly other grand-parents) of all source-control. We used it for a while at our (pretty small) company and switched to SVN (mostly because of the money issue). For that period (about six months) I couldn't see why P4 is considired so much better than (most) other VCS nor any of the guys saying it's the best could tell me why he thinks so. Tell us your arguments, please.

  • mwtb (unregistered)

    I think this has been a useful comment thread for once as it exposes why source-control WTFs are so common -- lots of people to fall into the trap of believing that source-control methodology is amenable to universal statements of good vs. bad.

     
    The appropriate source-control tool and mode of use is entirely dependent on the development context and anyone who thinks they can carry their personal likes and dislikes from project to project as a guiding beacon of good practice is a problem about to happen. "I used branches once and merging was a nightmare and so branches are evil." is a great attitude as long as you never have to deal with a scenario where decisions on what needs to be in a release version can't be made before you start developing. Source-control is as much an extension of project management skills as it is a technical issue and experience tells me that there are a lot of programmers who need to be kept well away from decisions about source-control procedures because they can't see beyond how it affects them.

     

  • TheLegend (unregistered) in reply to mwtb

    It's not rocket science to use svn (and to al lesser extent its older and stupider cousin cvs) properly:

    All developers develop in trunk.  All developers commit often at least twice a day). When you are releasing, tag _and_ branch (tags and branches are just hard links on linux so space isn't an issue). Any fixes/updates to be done on that release, do them in your branch, and merge them back into trunk (along with test cases of course) ASAP. As you release from the branch, simply tag again. Next major release, branch/tag from trunk again. If you need to revert you can use your tags, which provide a complete history of what has ever gone into production. Easy. Anyone who thinks branching is difficult is doing it wrong. Anyone using sourcesafe is doing it wrong. I never used clearcase so I can't speak from experience, but an ex-colleague was a huge fan and he was a dumbass, so that puts me off.

  • Local guy (unregistered) in reply to TheLegend

    Real programmers don't need source control; they code it perfectly the first time, every time, and it always works as written!

  • (cs)
    jdieter:

    WTF are these WTF so long for!!!!

    Are you writing a freaking book!

    is there a 1000 word minimum now???? 

    WTF is your problem with the post? Are the words too big for you too?

    If it takes that many words to describe the WTF, it takes that many words.

    It always amazes me when people criticize the posts (or software) here. Nobody's forcing you to visit this site or read the posts. Don't like 'em? Don't point your browser here. 

  • Anonymous Coward (unregistered)

    At least people get time off on and around Merge Day.  The opposite is true for M$'s monthly Patch Day.

    captcha: null

  • anon (unregistered) in reply to Sad Bug Killer

    I used clearcase at two different large shops. I didn't like it. Clearcase needed an full time admin to baby sit it since it would get corrupted.

    At my current shop we are using Accurev.  It works very well for smaller projects <  10 developers or less.   But we starting to run into limits in it ability to do complex multi branch merges.
     

    We are starting to look at Perforce...

     

     

  • (cs)

    I think most would agree on: branch when necessary and merge asap. and the technical reasons for branching should be:

    1. to achieve integrity between teams, and
    2. to enable easy rollbacks (just drop the branch)

    Basicly, branch when you to risky stuff or if you have louse developers (that makes everything risky). Given that there is no conincidence that Big Tech want to branch as much as possible... *oops* maybe shouldn't have said that. 

    But there are other views on branching and merging. As projects come and go; working on the same codebase, the development team shifting, upgrades happen and parallel development actually occur and is needed most organisations learn that sometimes they should have had branches so they could rollback. They certainly learn when they need to branch and merge. This, I think, lead to an organisation specific merging and branching routine, or strategy. This said I do not automaticly agree with "everyone should work in the trunk and branches should be created at the time of incremental releases". When having parallel development, which I think is pretty common out there. I would suggest; keep TRUNK clean, have branches per project, deliver on the project branch and then continue with bugfixes on the same. Still merging, should be done mean-while from the project branch, to TRUNK when you go live and possibly to other project branches if/when required.

    My 2 cents.

    /thurc

  • Wombat (unregistered) in reply to thurc
    thurc:

    I would suggest; keep TRUNK clean, have branches per project, deliver on the project branch and then continue with bugfixes on the same. Still merging, should be done mean-while from the project branch, to TRUNK when you go live and possibly to other project branches if/when required.

    Yep, this is what we do and it works quite well.  We use CVS - sometimes the merging needs a bit of CVS kung fu, but most of us know what we're doing with it, so that is fine.

     

  • Boomerang (unregistered) in reply to Disgruntled DBA
    Disgruntled DBA:

    9 days for the junior programmers doomed to fail

    7 days for unit testing on their laptops so slow

    3 days for rushed QA biting their nail

    1 day to halt them all, 1 day to find them.

    1 day to bring them all and in the darkness bind them.

     

     

    Yeah, it comes out to 20 days per month.  Apologies to Tolkien.

     

    That's 21 days altogether   :o). 

  • irked (unregistered) in reply to huh
    huh:

    If Big Tech is who I think they are, then ediabitzocity59line.com got what they deserved.  Big Tech has fucked up every piece of software they've touched in the past 50 years.  Big Tech has botched every concievable kind of software- operating systems, compilers, spreadsheets, database servers, and every type of industry specific application; you name it, Big Tech has written the "worst of breed" in every last category.

    Assuming we're thinking of the same Big Tech, "worst in breed" is EXACTLY the phrase that's been rattling around in my head since I started heavily using their software (and hardware) a few years ago. What crap. At least my company has their top-level enterprisey synergies and leverage their I.T. portfolios by proactively applying win-win economies of scale, or some such drivel. 

    huh:

    Big Tech's most important contribution to software development has been providing case studies for everyone else to read, so we don't repeat their antics. 

    Big Tech has some nifty hardware patents, though.  They're why we can have TB drives.

    Now I know we're talking about the same company. Big Tech makes around ONE BILLION DOLLARS (say it like Dr. Evil) annually just on software patents, so it's at least good for them. And what's good for them is good for America, right?

  • Fran (unregistered) in reply to thurc

    Aw - you all thought I was afraid of branching :) Actually, with AccuRev, there are no branches.  (*HUGE GRIN*)

    Its a completely different technology (a better technogology if you ask me) then the whole branch and merge thing.

     In AccuRev every developer has their own workspace.  When they promote (check-in) they're code, AccuRev automatically looks for conflicts and the developers resolve the differences right then and there.  Get this - developers can see any conflicts between there code and existing code throughout the entire code structure right from their workspace.  They can see the conflicts with the QA code, with the Production code - ANY and ALL existing code bases.

     There are "streams" - which are similar to branches...but not...

    So...you have a stream for version 1.0.  You make changes.  Now you want those changes in the 2.0 stream too.  So rather than jumping through hoops, and re-coding, etc, you just send files from stream 1.0 to stream 2.0.  (Change Palett) Again, if there is a conflict, AccuRev will automatically tell you and you resolve it then and there.

     Developers can even send code back and forth between their own workspaces before promoting it! (Checking it in)

    Our ability to do truely agile development has simply SKYROCKETED since we implemented.  I've never had a CM role where I had more control and oversight and fewer problems.  The developers rarely growl, and a recent audit by an external company gave our CM processes the highest possible rating!  (This is in spite of the fact that we are not a company with fully mature processes yet, and the audit found problems in literally every other area.)

     So, on that glorious note, I say again:  I haven't seen a branch in almost two years, and I hope I never do again! :) 

     

    Happy Merge Day!!

     

  • melvin (unregistered) in reply to trav
    Anonymous:

    It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.

     A clear case of finding a comple/enterprisey solution for a simple product.

    Hear, hear! Takes notes, people - irad I read somewhere that Big Tech gets its cics kicks from befouling everything it gets its claws on. At the  sametime it rexx wrecks everything in its wake, toppling good software like so many dominos. This is based on experience - it isn't just web smear.

    A rose (or turd blossom) by any other name would smell as sweet. Ok, I'll go from being critical and verbose back to Mostly Quiet...

  • The Unmanly Man (unregistered) in reply to KenW
    KenW:
    jdieter:

    WTF are these WTF so long for!!!!

    Are you writing a freaking book!

    is there a 1000 word minimum now???? 

    WTF is your problem with the post? Are the words too big for you too?

    If it takes that many words to describe the WTF, it takes that many words.

    It always amazes me when people criticize the posts (or software) here. Nobody's forcing you to visit this site or read the posts. Don't like 'em? Don't point your browser here. 

    Personally, I like the stories that Alex writes to describe the WTF's (he writes rather well), and find the WTF's an added bonus.

    captcha: whiskey - why yes, thanks, I'll have a tall one now!

     

  • (cs) in reply to anon
    Anonymous:

    I used clearcase at two different large shops. I didn't like it. Clearcase needed an full time admin to baby sit it since it would get corrupted.

    At my current shop we are using Accurev.  It works very well for smaller projects <  10 developers or less.   But we starting to run into limits in it ability to do complex multi branch merges.
     

    We are starting to look at Perforce...

     

     

    You could just hop on to SVN too, it's free, it's open-source, it works on and with everything, and it has a bazillion different clients.

    Anonymous:

    Aw - you all thought I was afraid of branching :) Actually, with AccuRev, there are no branches.  (*HUGE GRIN*)

    Its a completely different technology (a better technogology if you ask me) then the whole branch and merge thing.

     In AccuRev every developer has their own workspace.  When they promote (check-in) they're code, AccuRev automatically looks for conflicts and the developers resolve the differences right then and there.  Get this - developers can see any conflicts between there code and existing code throughout the entire code structure right from their workspace.  They can see the conflicts with the QA code, with the Production code - ANY and ALL existing code bases.

     There are "streams" - which are similar to branches...but not...

    So...you have a stream for version 1.0.  You make changes.  Now you want those changes in the 2.0 stream too.  So rather than jumping through hoops, and re-coding, etc, you just send files from stream 1.0 to stream 2.0.  (Change Palett) Again, if there is a conflict, AccuRev will automatically tell you and you resolve it then and there.

     Developers can even send code back and forth between their own workspaces before promoting it! (Checking it in)

    Our ability to do truely agile development has simply SKYROCKETED since we implemented.  I've never had a CM role where I had more control and oversight and fewer problems.  The developers rarely growl, and a recent audit by an external company gave our CM processes the highest possible rating!  (This is in spite of the fact that we are not a company with fully mature processes yet, and the audit found problems in literally every other area.)

     So, on that glorious note, I say again:  I haven't seen a branch in almost two years, and I hope I never do again! :) 

     

    Happy Merge Day!!

     

    Ok so Accurev has branches, can merge between them, but since it forces you to do it often you don't realize that you're working with branches and are therefore happy.

    Good for you, I guess.

  • (cs)
    Alex Papadimoulis:

    I'll call this person Ant; the reason being, there is a software tool bearing the same name that does exactly what he does...

    Jim actually prototyped and demonstrated a software package that could automate and accomplish the entire deployment process in a fraction of the time and eliminate the possibility of human error. Naturally, he was shot down by one of the lead developers; actually, the very same lead who designed the whole branching and Merge Day process in the first place. His reason: "I made a makefile once in college; they're more trouble than they're worth."

     

    I thought we were calling him Ant?

    Ironically, the guy who wrote Ant in the first place wrote it in large measure because he dislikes Makefiles, although he still uses them occasionally.
     

  • (cs) in reply to anon

    I've seen that kind of thing with ClearCase more than once. The good news is that it can handle distributed source repositories. The bad news is that you probably don't want it to.

  • Xetra (unregistered) in reply to Boomerang

    Err, its 22!

     captcha: 1337 ... damn right!

  • Fran (unregistered) in reply to Xetra

    "Ok so Accurev has branches, can merge between them, but since it forces you to do it often you don't realize that you're working with branches and are therefore happy."

     Let's see...

    No mass merging...

    Code shared between multiple versions without re-coding...

    Conflict resolution against multiple baselines (instead of one at a time)...

    Ability to see potential conflicts not only between streams but even between two developer's seperate workspaces and deal with it ahead of time...

    No merging at all beyond development...

     By God you're right!  I am happy :)

  • (cs) in reply to The Unmanly Man
    Anonymous:
    KenW:
    jdieter:

    WTF are these WTF so long for!!!!

    Are you writing a freaking book!

    is there a 1000 word minimum now???? 

    WTF is your problem with the post? Are the words too big for you too?

    If it takes that many words to describe the WTF, it takes that many words.

    It always amazes me when people criticize the posts (or software) here. Nobody's forcing you to visit this site or read the posts. Don't like 'em? Don't point your browser here. 

    Personally, I like the stories that Alex writes to describe the WTF's (he writes rather well), and find the WTF's an added bonus.

    captcha: whiskey - why yes, thanks, I'll have a tall one now!

    Another vote for well-written story WTFs from my side, Alex. As for the length - for my taste, some of the WTFs are still too short or miss some vital information to have a better judgement on the de facto WTF-ness... but then, this is the ***Daily*** WTF. Keep up the good work!

  • Anonymous (unregistered) in reply to Ether
    Anonymous:
    It's amazing how most people do branching totally wrong.  It's not actually that hard when you think about the problem you need to solve

    Please excuse the extreme noobieness.

    Can you point me some good articles, documents, howtos, books, or whatever that describe best practices for source control?

    Everything I find when I google always turns up to be 95% about the mechanics of using a sourse control system. I haven't every been able to find good documentation that tells me why I would use this feature or that.

  • Anon Anon (unregistered) in reply to irked

    Hello. This company is one of the big online travel companies. Look at the acronym:  ediabitzocity59line.com

    It stands for: Expedia, Orbitz, Travelocity, Site59, Priceline
     

  • BA (unregistered) in reply to Anon Anon
    Anonymous:

    Hello. This company is one of the big online travel companies. Look at the acronym:  ediabitzocity59line.com

    It stands for: Expedia, Orbitz, Travelocity, Site59, Priceline
     

    Ah, Site59. I had guessed most of the others, but didn't know of one that ended with a number. 

  • ClearCase luv'a (unregistered) in reply to BA

    I've used CVS, PVCS, VSS and ClearCase.  I like ClearCase the best for large teams, CVS/SVN otherwise.

    CC's dynamic views and, especially, the config-spec are really nice tools as long as you know how to use them.  The biggest problem is the learning curve.  It seems like the majority of people who hate ClearCase came from places that were using them poorly.

     

    Another thing I like is that, in ClearCase, directories get revisions just like files (something CVS does not do, but I think SVN does).  It also remembers when merges happened on an element - they aren't just moments in time where the file/dir changed but actually entities in the revision history that can be viewed graphically.

     

    I also have friends who love Perforce, but I've not had the opportunity to play with it. 

     

  • (cs)

    "I made a makefile once in college; they're more trouble than they're worth."

    It is this very trait that proves to be the downfall of humanity. The stubborn ability to remain with, or should it be the inept disability to escape from, one single narrow-minded way of doing things with such a low-value single-sentence logic. Such mis-enforcements produce increasingly damaging results as the people are stationed higher up the ladder of power. It is quite amazing to witness how irrational people really are, evidenced by unqualified individuals placed at various stations of responsibilities.

    PS - nice CAPTCHA word there... LOL

  • (cs) in reply to Xetra
    Anonymous:

    Err, its 22!

     captcha: 1337 ... damn right!

    No it isn't. Note that the last three "1"s all refer to the same day!

Leave a comment on “Happy Merge Day!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article