• (nodebb)

    Exactly how is Git the solution here? Subversion has branches, and has support for hooks to run unit tests. That aside, the more valuable improvement would be moving common code into reusable libraries, regardless of source control system. In short, Elliot is a moron, and Doreen is the typical "heard the ringing but doesn't know where it's coming from" type: she knows there's a problem, but did irrelevant things which only pissed off Elliot.

    Addendum 2021-09-22 06:39: PS. Let's use a distributed version control system. With a server. 🤦‍♂️

  • LCrawford (unregistered)

    the more valuable improvement would be moving common code into reusable libraries

    And with Elliot's thought process, soon there would be the "Library for Initrode" , the "Library for Soggy Beans", etc.

    Subversion has branches, but merging is a pain compared to Git.

  • Jaloopa (partially registered) (unregistered) in reply to LCrawford

    Subversion has branches, but merging is a pain compared to Git.

    People always say that, but I wonder how many have actually used Subversion in the last decade compared to the number who are just parroting what other people have told them.

  • NtH (unregistered)

    Should have just checked out each branch in it's own folder then he would have been happy and you could still work with git as intended.

  • Sole Purpose Of Visit (unregistered) in reply to Jaloopa (partially registered)

    I've been using it for every working day of the last ten years, so I'm in a position to offer a thorough yet anecdotal answer. Branching in Subversion is and always has been an utter pain in the patootie.

    I'd actually prefer Perforce in a case like this (three years using it on a massive code base; not a single problem with versioning). But heck, yes, Git (or Mercurial or whatever) would do the trick nicely. Just as long as you use the relevant tool in the manner expected. Elliott's approach is pure madness.

  • Naomi (unregistered) in reply to Jaloopa (partially registered)

    Oh, me! It's fine, but I'd definitely find it frustrating to use it with such a complex branching structure. (Well, more frustrating.) That said, I definitely have more experience with git, so maybe I'm just biased. /shrug

    All that said, I feel like the advantages of a distributed VCS become more and more relevant the more you've got going on in your repo.

  • (nodebb) in reply to NtH

    I do this all the time, except I use git worktree to have the same Git repository checked out in multiple folders.

    This saves me from having to have separate clones per branch, it's just one single repo clone checked out in multiple places.

    It also means that each worktree folder sees any other worktree folder's commits and references (since they're sharing the same .git folder) meaning that I only have to fetch once and all the worktree folders have all the commits available to them.

  • Prime Mover (unregistered)

    Dunno about soggy beans, but I've suddenly got a craving for mushy peas, with chips and fish and a battered sausage and a pot of curry sauce to pour over it.

  • NtH (unregistered) in reply to Jonathan Lydall

    Jonathan that's super handy to know! If only the git documentation had some resemblance of being human readable I might have found that option earlier.

  • Brian (unregistered)

    I never did understand the adoration for Git, other than plain old cargo cult mentality. The documentation is atrocious, the commands are completely unintuitive, and the whole distributed repo thing is not really a significant benefit in most environments. Honestly, I'd prefer something like Perforce or even TFS for a professional-grade shop. But hey, Git is the New Hotness, so let's go through all that unnecessary pain to look like the cool kids on the block.

  • my name is missing (unregistered)

    I worked at a financial institution in the mid 00's where our bank's software systems were stored in some proprietary "version control" system. Branching involved duplicating every file into a new file, which generally took all day since there were 1000's of files. I convinced them to switch to subversion which was way faster. Today using something more modern like git would make it trivial (long gone from there, for all I know, they are still using subversion).

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Jonathan Lydall

    I've been using git for many years now and had never even heard of git worktree before. That looks really useful—thanks for sharing!

  • Tom (unregistered) in reply to NtH

    What do you mean? I think the git documentation is just fine ^^ https://git-man-page-generator.lokaltog.net/#cGFjayQkc3RhZ2U=

  • (nodebb) in reply to Prime Mover

    Dunno about soggy beans, but I've suddenly got a craving for mushy peas, with chips and fish and a battered sausage and a pot of curry sauce to pour over it.

    TRWTF: We have no "Like" button for comments!

  • (nodebb) in reply to Prime Mover

    For some reason when I read "battered sausage," instead of...say...a sausage that had been dipped in batter (and then presumably fried or something), I imagined one that had been smacked around with a stick a few times...

  • (nodebb) in reply to LCrawford

    I never had any problems merging in subversion or any centralized system like TFS. In subversion, it auto merges what it can, and gives you a nice interface to go through conflicts, just like Git. Git only adds the ability to have what are essentially offline commits which you can push later, for example when connected. However it's strange to tout it as a benefit at the same time with deployment of 5G and 2GBs fiber optic home internet and world wide satellite internet. Most airlines above the low cost level have on board internet, too. (As if you'll complete so much work in a flight that you absolutely need to commit multiple times)

    In this case, the code has to be moved into a single repo; a series of trunk-branches relationships have to be established; common code has to be extracted into shared libraries; and yes development practices have to be improved, such as unit testing and overall code quality, i imagine. Git does not address any of these points.

  • Alex Vincent (google)

    It sounds like Elliott would've been happier with Subversion. That's how they manage branches: everything in the same repository.

    I had a manager (actually, the best I've ever had) say to me when I was a junior engineer, "Disk space is cheap."

  • tbo (unregistered) in reply to Bananafish

    That's a feature, not a bug.

  • Anonymous (unregistered) in reply to Jaloopa (partially registered)

    I'm sorry, but... I introduce my students to both Git and SVN, and the students always favor Git of their own accord. SVN is a dead meme; it no longer replicates into new minds.

  • (nodebb) in reply to Anonymous

    I'm pretty sure support from today's students isn't quite the ringing endorsement that you seem to think it is. (I'm being extremely diplomatic here)

  • ZZartin (unregistered) in reply to Jaloopa (partially registered)

    People always say that, but I wonder how many have actually used Subversion in the last decade compared to the number who are just parroting what other people have told them.

    It's kind of like arguing about what's better myspace or facebook, they both basically did the same thing and neither was better or worse but one ended up winning in the end just because.

  • Loren Pechtel (unregistered)

    While source control is a good idea that's not the issue here.

    Extract the common code! Use objects so the extra features are easy to inject into the base.

  • Valid Gripe (unregistered)

    Get Elliot a git GUI that assuages his lack of purview. Some people are visual and/or require more of a sense of certainty.

  • Fred Fredstone (unregistered)

    "I don't like this magical nonsense. I want to see our code in folders, as files, not this invisible shapeshifting stuff! I don't want our code where I can't see it!"

    This is not unreasonable at all.

  • Scratched that itch (unregistered) in reply to Jonathan Lydall

    I do this all the time, except I use git worktree to have the same Git repository checked out in multiple folders.

    Now that is a revelation, and I definitely know what's the first thing I'll be doing at work tomorrow.

    I knew that fossil (https://fossil-scm.org/) had that feature, but admittedly I already found it hard to justify using it for personal projects, so there wasn't gonna be any hope whatsoever of introducing fossil in a company.

  • My name (unregistered)

    Ah yes - the bane of all sane people - Stupid people in authority positions. Never gets gold

  • ooOOooGa (unregistered)

    I only ever used subversion in college. I didn't like it. I used Perforce for a couple years at work in 2013. It worked well enough, but it bothered me that I couldn't have the full power of a version control system on my work computer. All branches had to be made on the central server. So creating a new branch was taboo. I was given one personal branch to do all of my development work on. No matter that I may have to hold off on completing a ticket that I have half finished because of reasons and want to start working on another.

    Other than that, I have only ever used git. It does the job. It is free. The documentation is passably good. What's not to like?

  • Grunthos the Flatulent (unregistered)

    GIT is cool only by association because Linux is supposedly cool and that was written by Sweary Torvalds (although he only wrote 2% which is hardly anything - if I put two baked beans in a tin I can bearly claim to be a "baked bean tin packer"). This just goes on to pander to his ego (why else would he name it after himself and not his childhood dog or crush?)

    As two people have pointed out disk space is cheaper (I was told the same back in the 80's) and why are obfuscating the process of really simple UTF8 text files in folders?

  • Jon (unregistered)

    Maybe it's just me, but I have found SVN a lot easier to explain to non-technical users than git. You can explain SVN in terms that most people are familiar with (branching = copy a folder!), but it seems the abstract power of git is really REALLY hard for non-technical people to understand.

    So, in my line of work (insurance/reinsurance), if I was asked which type of software version control I'd like to set up from scratch, I would recommend SVN. Not because it's better than git, but because it's more likely that the users will be able to understand what's happening.

  • Worf (unregistered) in reply to Brian

    There aren't many distributed source control systems out there. There's Mercurial (Hg), BitKeeper and Git are the main big ones.

    Git derived from BitKeeper in operation - BitKeeper uses SCCS internally and was used in the early 2000's when Linus Torvalds finally decided to end patch madness and put Linux into source control. BitKeeper wasn't open-source, but it had paid and free versions. The difference was the free version send all commit logs to an openlogging server which was publicly viewable.

    Unfortunately, as with anything closed source, there were people angry at using it and one of them tried to write a BK to CVS exporter and caused Linux to get thrown off the platform.

    Git came about because Linus needed source control for Linux and deciding that he couldn't find anything that could scale very well (even BitKeeper stunk at handling kernel sized repositories), he wrote his own.

    Git is actively developed, isn't too slow (important when you're handling repositories in the gigabyte of size with tens of thousands of files), and is popular because it's open source and works well with the open-source development methodology. It's trivial to fork projects (a clone contains the entire history of the project) and thus is basically the open-source development methodology.

    So it's popular because Linux uses it. It's popular because it's actively developed. There are many projects between GitLab, GitHub, Gerrit, Phabricator, and many others that build it in internally and handle code reviews, code checkouts, pull requests and other things. And because real developers use it in real time, anytime you make an error in the repository, almost always someone has a way to fix it because someone else has seen the same problem.

    Plus, the data model is simple - everything is an object, and the object store is just file hashes. A commit is a list of hashes representing files, and a hash of the parent commit. A reference (e.g., branches, tags, HEAD, etc) are just references to commits.

  • Paulina (unregistered)

    I'm now living in a comparable hell, with a tech lead that has reinvented many common things 5 years ago and now still makes everybody use them. I have been thinking about how these "challenged" developers can end up on top. My current theory is that all capable developers move on, and the not-so- good automatically get promoted. In the mean time, the company gets locked in with all the bad design choices made and will remain so until it goes out of business.

  • (nodebb) in reply to Worf

    Git came about because Linus needed source control for Linux and deciding that he couldn't find anything that could scale very well (even BitKeeper stunk at handling kernel sized repositories), he wrote his own.

    The statements I remember seeing at the time said something different - BitKeeper removed the exemption that allowed the kernel developers to use it for free or at a hugely reduced price, and full price would have been aggressively punitive.

  • (nodebb)

    Conversely, a small company is more restricted- you have to work hard to keep your customers happy.

    Oh gawd yes. If I had a penny for every time a customer said "But it works when we try it with $bigcompany's software who have never heard of standards and in some cases have required reverse-engineering binaries in order to figure out WTF it is they're doing", I wouldn't be working in software any more.

  • (nodebb) in reply to Mr. TA

    Most airlines above the low cost level have on board internet, too.

    Not on long haul they don't. Internet access when over the ocean is at best theoretical.

  • chris (unregistered)

    As others have stated, the article is written in a way that people of the cargo cult can read it as "subversion was the initial problem", which is completely incorrect. The moron manager refused to use branches in svn and then refused to use them in a reasonable way in git, so he abused both version control systems in equally stupid ways. But either Remy or the submitter was also trying to make a completely misguided shot at "this was subversion's fault", which is just as stupid as the manager in question

  • mushroom farm (unregistered) in reply to Jaloopa (partially registered)

    I have used SVN for 2 years, 2016-18. Git is far better for branching and merging.

  • Randal L. Schwartz (google) in reply to Jonathan Lydall

    I was gonna say... git worktree for the win. I have frequently used it for a scorched earth rewrite for a client. Check out old version in a separate worktree, then create a new version and copy-paste back and forth.

  • test (unregistered)
    I was gonna say... git worktree for the win. I have frequently used it for a scorched earth rewrite for a client. Check out old version in a separate worktree, then create a new version and copy-paste back and forth.

    yes [spoiler name=xxx]and further more[/spoiler]

  • test (unregistered)

    [code=python] def nothing(x): return x + 1 [/code]

    [code=c++] int nothing(int x) { return x + 1; } [/code]

  • test (unregistered) 
    int nothing(int x) { return x + 1; }
  • Gnasher729 (unregistered)

    When I started at my current company, they had two branches for two different versions of the software. Then my boss told me we would have to add two more branches soon..,

    So I added an empty config file to each branch with a different name, created two compiler targets that would use each config file. Then a diff between the branches.

    Any difference: Either I decided that the difference shouldn’t be there and made the branches the same. Or it was an intentional difference. Then some configuration was added to both configuration files and the code made identical. Or the same configuration reused.

    Configuration could turn features on and off. So then huge differences would be configured with one little configuration. Within a week both branches were identical except for the configuration file, and then one branch was removed.

    Then version 3 and 4 had to be created. Which was just setting up two new build targets and two new config files. And then my boss could say “version 3 will have features a, b, e out of a to e, and that was five little changes in the configuration files!

    I just can’t imagine how people live with 50 or 200 branches! 200 config files is bad enough!

Leave a comment on “Some Version of a Process”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article