"We don't use SVN and stuff here"



  • OK, so I've switched jobs since the last time I talked about my job. It wasn't a voluntary switch, but looking back I should have up and went ages ago: I guess hindsight is twenty-twenty. I now earn 200 euros a month more, after tax, working four hours a week less than I used to. If they offered me another four hours less, and another two hundred after tax extra, I would probably decline their offer. I'm going to talk about source control as implemented over there, which I'll call ZeroByte.

    So ZeroByte was formed around 2000-2002 by a guy who sort of rolled into it, and who'd studied Communication or Product Design or something like that. About 7 years ago, he was joined by a buddy of his, who had been a car mechanic up to then and AFAIK had never written much code at all. Both have taught themselves and/or each other everything they know.

    The latter dude is TRWTF basically, since he doesn't know how to manage intelligent people, and he's not exactly a rocket surgeon: nothing wrong with that in itself, but maybe you shouldn't be a software developer if you can't think out of the box. He can be a nice guy, but he wants to have the last word in every conversation, to the point where he simply makes up arguments on the spot. I suspect he doesn't know he does that, but he did it to me lots of times. No bitter ex-employee bias there, I'm talking about provably false facts that I know for certain he fabricated off the top of his head, just to use to argue against my points. I was the only one on the payroll, the other two guys both have a 50% stake in the company, and the former guy backed the latter guy out of... Well actually I don't give a shit out of what. Couple that with "not exactly a rocket surgeon" and you've got a recipe for some tasty and spicy WTF hot sauce.

    Did I mention that ZeroByte is a PHP shop?

    Back to source control. It was implemented by the age old strategy of "there's a network share over at address X, try not to fuck up too badly". I had no education to speak of, or a real portfolio to show them, so I was allowed only on a share with smaller projects at first: fair enough I suppose. Some of the stuff they were more protective of, they had on another share. They did weekly or daily backups of their code, and each backup would overwrite the last.

    So, fun stuff I would encounter often included:

    • - "Hey, my editor tells me my somecode.php changed on disk, I'm working in that file! Who else is working in that file?"
    • - "Who changed this function?"
    • - "Who changed this function? That change is bad but obviously now we can't change it back without finding a duplicate of the old function somewhere!"
    • - "Before you work on somecode.php, be sure to make a backup somewhere in case you mess up and we need to revert!"
    • - "How old is this code, was this changed before that one big bug of two months ago, or after?"
    • - "This change is bad and it's your fault! [...] Well me and [the other owner] would never do such a thing so it has to be you!" Guess which one of the guys would coin that particular one a lot?

    I pleaded for some kind of VCS. Why? Because no matter which one you choose, you can work together, you can see who did what and why, and if somebody fucks up (even outside of ZeroByte, nobody is, after all, perfect) you can revert their changes. All of the things I mentioned above (I'm sure some of you can think of even better examples) are arguably objectively bad, and can be avoided with all source control systems I know, even Visual fucking SourceSafe.

    Three notable incidents stand out, looking back.

    The first one is the demise of the box on which the shares were located. No coding could get done for about a week. There was the aforementioned backup, but without a network share, well good luck with that. Our workstations were Windows boxes and the backup was on an ext[something] file system. Only one thing for it, set up a new server ASAP. I got paid to sit at home and twiddle my thumbs, and we were really lucky no important release was planned that needed work in that week.

    The second one was me hinting one of the guys, "Man I'm working on this bug; I can't figure it out because I find the code hard to grok; it would be so easy if only I knew what changed in this directory since a week ago, because everything was OK a week ago." and him telling me with a straight face "well, that's obviously impossible no matter what" (the exact word he used was sowieso instead of "no matter what"). Well I know of a way, and it's not like we hadn't discussed VCS ever.

    The third one was the Search/Replace debacle. We used Komodo Edit, which is not an IDE (although a Komodo IDE exists), but it's decent enough and supports grouping files into projects. It's not bad at all, considering it's free as in free beer. One of the things Komodo Edit also supports is project-wide Search-and-Replace. So one of the guys (again, guess which one) was working on one of their two flagship products. It was on the protected share, and it was decided that I was to get permission to join them on it. So around that time, this dude accidentally searches the entire project for a string, and it was pretty important, let's say "shipment" or "invoice" or something, and replaces it project wide with the empty string. You can set up Komodo not to warn you, and you guessed it: he'd done just that.

    They found out the day after, when the backup had already been run. I remember the first thing the guy did when confronted, was try to find ways to make this somebody else's fault somehow. Now, I don't mean, figure out where this went wrong, and I don't mean figure out who did it. I really mean, try to see if somebody else but him could have done it. There was the co-owner, who would probably not have been stupid enough to do that, also he had not been working on this codebase, and he was his friend. And then there was me. And I didn't have access to this share yet. He tried to pin it on me anyway. I don't remember how, but I remember being able to talk my way out of it without telling him I obviously could never have been able to do it.

    So why wouldn't they implement source control? Well they tried installing SVN. But they didn't really understand it. Also they wanted "support for modules" which meant they wanted to share code between repos (like plug a directory in, and changes in there are propagated among repos). They heard SVN supports that, but they didn't really understand SVN so they didn't know how easy or hard it would be to do that. They were sort of wary of VCS. I guess they figured it would be okay not to use VCS, if the only reason is you don't want to read a book about it.

    At my current workplace, we used to use Visual SourceSafe but switched to Git just last week. Now, I don't think I want to work anywhere where there is no real source control software in place.



  •  Yes, without good source control soft it is hard to work and I would refuse even try it :)

    Also one time I was working at company, where SVN was used. I later learned Git, but was not able to force it company-wide. So I was using it on my comp only, carefully preparing my commits and when it merged flawlessly, I commited the result to SVN. This way I had nearly all comfort from Git and my SVN commits was nice, clean, consistent and merged everytime :) 



  • @gilhad said:

     Yes, without good source control soft it is hard to work and I would refuse even try it :)

    Also one time I was working at company, where SVN was used. I later learned Git, but was not able to force it company-wide. So I was using it on my comp only, carefully preparing my commits and when it merged flawlessly, I commited the result to SVN. This way I had nearly all comfort from Git and my SVN commits was nice, clean, consistent and merged everytime :) 

    Torvalds says he's heard a number of stories of people doing that. Apparently, you're not the only one who does that by a long shot. I've personally not had any experience with SVN. I've only ever used VSS which I don't care for, and Git which I love. It's sort of a geeky love though, the way it works kind of gets my nerd juices flowing.



  •  Could this be associated with the Health Care rollout?  They probably use PHP there as well (no I haven't looked, or care to).


  • Discourse touched me in a no-no place

    @toon said:

    Torvalds says he's heard a number of stories of people doing that. Apparently, you're not the only one who does that by a long shot. I've personally not had any experience with SVN. I've only ever used VSS which I don't care for, and Git which I love. It's sort of a geeky love though, the way it works kind of gets my nerd juices flowing.
    We're gradually moving our software from SVN to Git; it's not a top-priority project (since it's not something that directly affects our users), but it is still recommended. SVN is majorly annoying, and comparatively slow (especially with larger commits), and won't work at all except for the most trivial operations when you're not connected to the central repository. Git is still annoying, but that's mainly because it is exceptionally complicated and doesn't hide the fact at all, yet it's streets ahead of SVN.

    Personally, I prefer some of the other DVCSs for having a workflow that fits my mental model better, but that's another matter. (They also fit better than SVN ever did.)



  • @dkf said:

    @toon said:
    Torvalds says he's heard a number of stories of people doing that. Apparently, you're not the only one who does that by a long shot. I've personally not had any experience with SVN. I've only ever used VSS which I don't care for, and Git which I love. It's sort of a geeky love though, the way it works kind of gets my nerd juices flowing.
    We're gradually moving our software from SVN to Git; it's not a top-priority project (since it's not something that directly affects our users), but it is still recommended. SVN is majorly annoying, and comparatively slow (especially with larger commits), and won't work at all except for the most trivial operations when you're not connected to the central repository. Git is still annoying, but that's mainly because it is exceptionally complicated and doesn't hide the fact at all, yet it's streets ahead of SVN.

    Personally, I prefer some of the other DVCSs for having a workflow that fits my mental model better, but that's another matter. (They also fit better than SVN ever did.)


    This might be helpful.



  • @dkf said:

    @toon said:
    Torvalds says he's heard a number of stories of people doing that. Apparently, you're not the only one who does that by a long shot. I've personally not had any experience with SVN. I've only ever used VSS which I don't care for, and Git which I love. It's sort of a geeky love though, the way it works kind of gets my nerd juices flowing.
    We're gradually moving our software from SVN to Git; it's not a top-priority project (since it's not something that directly affects our users), but it is still recommended. SVN is majorly annoying, and comparatively slow (especially with larger commits), and won't work at all except for the most trivial operations when you're not connected to the central repository. Git is still annoying, but that's mainly because it is exceptionally complicated and doesn't hide the fact at all, yet it's streets ahead of SVN.

    Personally, I prefer some of the other DVCSs for having a workflow that fits my mental model better, but that's another matter. (They also fit better than SVN ever did.)

     

    STOP - move to hg instead

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

     



  • @Helix said:

    STOP - move to hg instead

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    Well, our company looked into Mercurial, and have yet to figure out how it's any better than Git, apart from the fact that TortoiseHg exists. Why should dkf and/or I move to Mercurial from Git?



  • @toon said:

    @Helix said:

    STOP - move to hg instead

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    Well, our company looked into Mercurial, and have yet to figure out how it's any better than Git, apart from the fact that TortoiseHg exists. Why should dkf and/or I move to Mercurial from Git?

    Don't. Git is better.



  • @Helix said:

    STOP - move to hg instead

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    Hang on, I think I get it. You meant the company my post was about! Sorry; I figured you were trying to get involved in the discussion in the comments.

    Well, I expect they'll need to adjust to every developer having a copy of the source code on their workstation, first. Don't forget, everybody there works on the same copy of the source code. Corollary to that fact: there is, apart from backups and staging/production copies, only one copy of the source code in existence at any given time. Having worked there for two years, I think they'll have a hard time thinking outside of that particular box, having been in it for over a decade.

    Once they make that step, which I doubt they will, then they'll need to get over the hurdle of not grokking how source control works. One of the two guys in particular. He'll keep getting bogged down in making mistakes and then trying to figure out how to undo them, because he'll want to erase them. I don't mean that to bitch on him, it's just that I know that this is how his mind operates. He'll feel that it's best to clean up your mess when you make a boo-boo, and he won't understand that you should either revert them with new commits/pushes/checkins, or think before you commit/push/check in.

    Godawfully annoying though SVN and CVS are reported to be, and I know Visual SourceSafe is, maybe Git or Mercurial are a few hurdles too far for those dudes. They'll be able to better grok SVN, and they won't have to be paranoid that "there's no central place for the code anymore" with Git.



  • @Ben L. said:

    @toon said:
    @Helix said:

    STOP - move to hg instead

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    Well, our company looked into Mercurial, and have yet to figure out how it's any better than Git, apart from the fact that TortoiseHg exists. Why should dkf and/or I move to Mercurial from Git?

    Don't. Git is better.

    I like that. You and me, we're not like those people who believe in things like books, or the news.

    OT, though, TortoiseHg is pretty cool. But if you download Git as an installer from the site, with no other software, you get shell extensions for Explorer, and a few GUI tools, and I've found those, coupled with a little command line now and then, to be perfectly adequate for my needs. I'd rather have a little more power and a little more flexibility than a few more icons.



  • @Helix said:

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    I agree. Git is convenient for developers but a nightmare for people who do release management full time, and SVN is pretty much the other way around.



  • @Ronald said:

    @Helix said:

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    I agree. Git is convenient for developers but a nightmare for people who do release management full time, and SVN is pretty much the other way around.

    I can certainly see why SVN would be convenient for people who do things like release management, I imagine that it's easy to keep tabs on what everybody's working on with SVN. I've only ever worked at small places so that sort of thing doesn't really apply; I can see why software like TFS, for example. can be great for a huge .NET place, because all the suits and PHB's can get nice reports. Worth the cost by allowing management to get a better overview of the process.

    As for Git being a nightmare for release management people, would you say that that sort of thing can't be solved with a good branching model? I mean, the system Torvalds uses with those lieutenants and stuff seems to work well for the Linux kernel. And you could set up different repos that only certain people can access, like a QA department.



  • @toon said:

    And you could set up different repos

    Having one repo for multiple projects is TRWTF



  • @Ben L. said:

    @toon said:
    And you could set up different repos

    Having one repo for multiple projects is TRWTF

    Visual SourceSafe does that. It's a WTF and no mistake.


  • Discourse touched me in a no-no place

    @Helix said:

    STOP - move to hg instead

    For us, the existence of github (including the social network effects) is a strong reason for going to git. The code's technically open source (the build is absolutely horrendous, but that's not to blame on SVN or git or any other SCM) so having the code be somewhere where others can see it is considered to be positive.
    @Helix said:
    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    There's a lot of variation in how DVCSs support the development workflow. Git might work well with very large teams, but for smaller, more tightly-coordinated teams it seems rather nasty; not only does it not require a central server, it positively encourages everyone to use their own labelings of the world. (For all that, it's better than SVN, which can get itself in a terrible mess. But that's like saying you're not as retarded as Corky the SAP Developer.) My personal favourite is Fossil (it comes with a load of stuff built-in, particularly an issue tracker which is great for working offline) but I'm under no illusions as to whether it's anything like as popular as other choices.



  • @toon said:

    @Ronald said:
    @Helix said:

    SVN = Sysadmin/architects view of how SCC should be controlled

    DVCS = How developers actually work on projects, particularly if they had no SCC in the first place.

    I agree. Git is convenient for developers but a nightmare for people who do release management full time, and SVN is pretty much the other way around.

    I can certainly see why SVN would be convenient for people who do things like release management, I imagine that it's easy to keep tabs on what everybody's working on with SVN. I've only ever worked at small places so that sort of thing doesn't really apply; I can see why software like TFS, for example. can be great for a huge .NET place, because all the suits and PHB's can get nice reports. Worth the cost by allowing management to get a better overview of the process.

    As for Git being a nightmare for release management people, would you say that that sort of thing can't be solved with a good branching model? I mean, the system Torvalds uses with those lieutenants and stuff seems to work well for the Linux kernel. And you could set up different repos that only certain people can access, like a QA department.

    If you work only on one project it does not matter. It's when you start having multiple overlapping modules/components/applications with shared artifacts (such as a unified data model or 3rd-party libraries) that things become pretty nasty if you can't orchestrate builds easily. In many organizations a major VCS with strong ALM features (like TFS or Rational) is necessary otherwise doing TDD or CI is impossible beyond the small team scope because of all the conflicting deployment sequences. To some extent in large organizations you even need to peek into a CMDB before you can promote a build to QA because large-scale testers need properly configured loads; doing that with individual tools is unrealistic.

    The Linux kernel project is a pretty amazing thing and even with a huge amount of contributors they remain somehow dynamic, but following their lead for source control in smaller projects is like deciding to use Cassandra for the data layer in an application because that's what Facebook is using or leasing a low-latency NASDAQ trading line for managing your investments because that's what JP Morgan is doing. That's the difference between "best practices" and "right practices".


  • Discourse touched me in a no-no place

    @Ronald said:

    In many organizations a major VCS with strong ALM features (like TFS or Rational) is necessary otherwise doing TDD or CI is impossible beyond the small team scope because of all the conflicting deployment sequences.
    I shudder to think what it must be like when building with C++, where there's major complexity in compilation and no truly standardised library mechanism. With Java, a fully mavenized build is a great thing because that enormously simplifies things; you've got a repository, a CI system, and a standard description of what to do, and working with it makes things typically quick and straight-forward. (Not that this stops smartass people from doing smartdumb things.)



  • @Ben L. said:

    @toon said:
    And you could set up different repos

    Having one repo for multiple projects is TRWTF

    I've yet to see any simple methodology as to how you share source code between projects in things like Git, e.g. A header file full of defines that are used in matching client and server projects. Sure VSS has its faults (and I know them backwards) but sharing code between projects was dead easy.



  • IMO any shop that doesn't use a VCS system is an automatic "No thanks" for me, unless perhaps if I was desperate and going to starve to death without a job. Lack of a VCS shows such a complete lack of any clues pertaining to modern development that I can't even fathom anyone intelligent working there.


  • Discourse touched me in a no-no place

    @OzPeter said:

    I've yet to see any simple methodology as to how you share source code between projects in things like Git, e.g. A header file full of defines that are used in matching client and server projects.
    Since git stores the entire state of the checkout in each checkin by design (it compresses well), avoiding duplicating shared code requires you to put the “shared” code in a different location instead of putting it all in one place. Then you use submodules to stick things back together, and don't change the shared bits if you can help it.



  • @OzPeter said:

    @Ben L. said:
    @toon said:
    And you could set up different repos

    Having one repo for multiple projects is TRWTF

    I've yet to see any simple methodology as to how you share source code between projects in things like Git, e.g. A header file full of defines that are used in matching client and server projects. Sure VSS has its faults (and I know them backwards) but sharing code between projects was dead easy.

    You mean like Source engine mods? Because I'm pretty sure any client/server program that shares code is a single project.



  • @Ben L. said:

    @OzPeter said:
    @Ben L. said:
    @toon said:
    And you could set up different repos

    Having one repo for multiple projects is TRWTF

    I've yet to see any simple methodology as to how you share source code between projects in things like Git, e.g. A header file full of defines that are used in matching client and server projects. Sure VSS has its faults (and I know them backwards) but sharing code between projects was dead easy.

    You mean like Source engine mods? Because I'm pretty sure any client/server program that shares code is a single project.

    More like external libraries or modules. Like, say you do a bunch of web projects, and you've got a bunch of in-house developed jQuery plugins that you want to pick and choose from, and plug into your repo. And then you want to have changes to each plugin, propagate among all repos, so they can all benefit from the changey goodness. I'm pretty sure that what you DON'T want is to think of every single web app you ever do as one big project. The company I currently work at switched to Git, but is still figuring out how to do that properly. Honestly I think they're best served coming up with a way to avoid trying to do that. I'm not sure management will think of that as a viable option though. Me and a coworker are the only ones actually using Git at this point, but our projects generally don't need to share code.

    Actually, the company I talk about in my post wanted to do much the same thing, except with PHP code from their CMS. They'd built modules that were supposed to be able to be plugged into any web site that used said CMS. One of their arguments against implementing VCS was, that they didn't know how to share modules between sites. They'd heard SVN could do that, but they needed somebody to come in and explain how it works, and until that happened SVN (which they always referred to as "Tortoise" except pronounced wrong) was simply too difficult for them to grok.

    I like where I work now. It's much better than working at "ZeroByte".



  • All I've used so far are VSS (which was set in exclusive lock mode because apparently its merging sucks, and given some of its diffs I'm willing to believe that) and Team Foundation which haven't given me any notable problems yet.



  • @toon said:

    Well, our company looked into Mercurial, and have yet to figure out how it's any better than Git, apart from the fact that TortoiseHg exists. Why should dkf and/or I move to Mercurial from Git?


    I present: TortoiseGit.



  • @studog said:

    @toon said:

    Well, our company looked into Mercurial, and have yet to figure out how it's any better than Git, apart from the fact that TortoiseHg exists. Why should dkf and/or I move to Mercurial from Git?


    I present: TortoiseGit.

    Are you suggesting that TortoiseGit is about as good as TortoiseHg? Because I, for one, wholeheartedly disagree. TortoiseHg is great! TortoiseGit, OTOH well, like I said: just run the Git installer and use the included tools.



  • Have any of the people hating on SVN in here actually used it recently?  Because to those of us who have, the complaints look laughably outdated.  It would be like me saying "Windows sucks because <insert horrible problem from Windows ME here>!"  In the last few releases, SVN has gotten much faster, with a new database model, better metadata, better merge support, etc.  And it's still *far* simpler to use than any DVCS I've had forced upon me by various projects, with a much more reasonable workflow.

    I generally look at DVCS the same way I look at NoSQL: it's useful if you're running a massive-scale project, but you're not, so stop trying to act like you're cool because you're copying what the people running these massive projects are doing without understanding why they're doing it.



  • @Mason Wheeler said:

    I generally look at DVCS the same way I look at NoSQL: it's useful if you're running a massive-scale project, but you're not, so stop trying to act like you're cool because you're copying what the people running these massive projects are doing without understanding why they're doing it.

    Well, I've never used SVN and I've never commented on SVN: having said that, I *have* used VSS which is a centralized system, with file locking. I've found Git to be extremely well suited for my needs, both on the job and off. I think SourceSafe harms my productivity by not allowing me to look at what happened to the code and by not allowing me to manage different versions of the same codebase (branching in SourceSafe? well you can just forget about THAT). And I've never done a really large project in my life. git works fiine for small projects, and VSS is not worth the effort. Actually, I honestly don't think Git becomes a better fit for a project as the project gets very large. If a project gets really huge, actually Git starts running into performance issues. The folks at Facebook use Git and their blames take several seconds, to the point of considering an internal Git fork, like they hacked PHP internally. The people at KDE had headaches trying to split KDE into smaller projects, because the whole chunk just wouldn't work well with Git, and apparently KDE has a lot of interdependencies.

    The point being two things: first of all, not many really massive projects seem to be using Git and those that do, do not seem to be shouting off the rooftops how awesome Git is. Perhaps you can point us to a few?Secondly, nobody here is saying they're cool because they're copying the big boys, and I think the ones of us in this thread who have been saying they like Git, have been pointing out why they like it, and you're trying to make it look like they're not. It's a strawman argument and that's cheating.


  • ♿ (Parody)

    @Mason Wheeler said:

    Have any of the people hating on SVN in here actually used it recently?  Because to those of us who have, the complaints look laughably outdated.

    I wasn't hating on svn in this thread, but it still has a fatal flaw, which is that it follows the merge-on-commit paradigm (which is OK if you're a team of one) instead of commit-then-merge. There's also the fact that you have to be able to connect with the central server, which is a severe to fatal flaw depending on the way you work. I haven't done a lot of merging, but it still seems more difficult than it is in hg, which is the DVCS I'm most familiar with.


  • Discourse touched me in a no-no place

    @toon said:

    Back to source control. It was implemented by the age old strategy of "there's a network share over at address X, try not to fuck up too badly". I
    Out of interest, what was to stop you implementing source control yourself somehow? Granted you'd be the only one using it, but you'd have at least some sort of (incomplete) history, even if you took the "check in any changes before I start changing stuff, check in any changes after I've changed stuff," just to catch what they've changed in the interim.


  • Considered Harmful

    @boomzilla said:

    @Mason Wheeler said:
    Have any of the people hating on SVN in here actually used it recently?  Because to those of us who have, the complaints look laughably outdated.

    I wasn't hating on svn in this thread, but it still has a fatal flaw, which is that it follows the merge-on-commit paradigm (which is OK if you're a team of one) instead of commit-then-merge. There's also the fact that you have to be able to connect with the central server, which is a severe to fatal flaw depending on the way you work. I haven't done a lot of merging, but it still seems more difficult than it is in hg, which is the DVCS I'm most familiar with.

    Yeah, being able to work while disconnected is a killer feature. It means I can continue to work without having to find a Wifi hotspot.

    Also, sometimes I start writing code on a whim, which may or may not grow into a full-fledged project someday. It's trivially easy to run "git init" before I start, creating a local repo I can immediately work with (even with no remote connectivity), and then I can scale that up later if and when I decide to.


  • Considered Harmful

    @PJH said:

    @toon said:
    Back to source control. It was implemented by the age old strategy of "there's a network share over at address X, try not to fuck up too badly". I
    Out of interest, what was to stop you implementing source control yourself somehow? Granted you'd be the only one using it, but you'd have at least some sort of (incomplete) history, even if you took the "check in any changes before I start changing stuff, check in any changes after I've changed stuff," just to catch what they've changed in the interim.

    I'm imagining some kind of interop set up with two users, "me" and "not me". Any changes that happen that aren't part of my own commits are auto-committed by the "not me" user. There'd some kind of daemon checking file hashes or something on the share and committing periodically.



  • @joe.edwards said:

    Yeah, being able to work while disconnected is a killer feature. It means I can continue to work without having to find a Wifi hotspot.

    Also, sometimes I start writing code on a whim, which may or may not grow into a full-fledged project someday. It's trivially easy to run "git init" before I start, creating a local repo I can immediately work with (even with no remote connectivity), and then I can scale that up later if and when I decide to.

     

    Why are you consistently conflating "work" with "check code in to source control"?  To me, "work" means "writing, testing, or debugging code," not "checking code in". That's what you do when you're done working on it.

     



  • @toon said:

    The point being two things: first of all, not many really massive projects seem to be using Git and those that do, do not seem to be shouting off the rooftops how awesome Git is. Perhaps you can point us to a few? ... It's a strawman argument and that's cheating.
     

    How about Linux, the poster boy for Git's supposed awesomeness?  You can't get any less strawman than pointing right at the actual source.

     


  • ♿ (Parody)

    @Mason Wheeler said:

    Why are you consistently conflating "work" with "check code in to source control"?  To me, "work" means "writing, testing, or debugging code," not "checking code in". That's what you do when you're done working on it.

    That's true-ish. It depends on the task. Anyways, if I'm not connected at the point I want to commit, it's a PITA. Sometimes I go a few days between commits. Sometimes just a few minutes.



  • @boomzilla said:

    @Mason Wheeler said:
    Why are you consistently conflating "work" with "check code in to source control"?  To me, "work" means "writing, testing, or debugging code," not "checking code in". That's what you do when you're done working on it.

    That's true-ish. It depends on the task. Anyways, if I'm not connected at the point I want to commit, it's a PITA. Sometimes I go a few days between commits. Sometimes just a few minutes.

     

    What does that even accomplish, though? DVCS enthusiasts are always talking about offline commits as if they were some revolutionary Great Thing, but I've never seen the point.

    There are two good reasons to check your code in: to share it with the team/the public, and to have a versioned backup somewhere other than your system, in case your system dies.  Local commits accomplish neither one, so what good are they?  (Not trying to troll here; honest question.)


  • ♿ (Parody)

    @Mason Wheeler said:

    There are two good reasons to check your code in: to share it with the team/the public, and to have a versioned backup somewhere other than your system, in case your system dies.  Local commits accomplish neither one, so what good are they?  (Not trying to troll here; honest question.)

    Commits are also used to group related changes. It's not just to have something backed up somewhere else. That's just a benefit of having a separate server. But if I need to back something out or locate the source of a problem later, it's easy to find, because there's a relatively small change (usually) indicated by a commit. With svn, if I cannot connect to the central server, I have to either keep working and hope that I can do piecemeal commits later. That may be possible if two tasks don't require changing the same file, but it's a PITA to have to go back and do it after the fact.

    It's possible that you are never or rarely out of contact with your version control server, and that's fine. But it sucks to have that situation make your life more difficult than it needs to be. I might also break up a task into smaller subtasks, but not want to share it until they're all done.



  • @Mason Wheeler said:

    @boomzilla said:

    @Mason Wheeler said:
    Why are you consistently conflating "work" with "check code in to source control"?  To me, "work" means "writing, testing, or debugging code," not "checking code in". That's what you do when you're done working on it.

    That's true-ish. It depends on the task. Anyways, if I'm not connected at the point I want to commit, it's a PITA. Sometimes I go a few days between commits. Sometimes just a few minutes.

     

    What does that even accomplish, though? DVCS enthusiasts are always talking about offline commits as if they were some revolutionary Great Thing, but I've never seen the point.

    There are two good reasons to check your code in: to share it with the team/the public, and to have a versioned backup somewhere other than your system, in case your system dies.  Local commits accomplish neither one, so what good are they?  (Not trying to troll here; honest question.)

    "Offline" does not mean that the client is not connected to internet, it could simply be that the source control server is out of reach behind a corporate firewall or a similar situation. So if you have developers that work from home or from various satellite offices it can be annoying because either they have to fire up a disrupting VPN client to commit, or they have to commit less often so they have less tools to troubleshoot or rollback things.

    I hate Git, it's a piece of shit that makes it difficult to schedule complex builds, but the DVCS element is something valuable that hopefully will make its way in more decent products in the future.



  • @Ronald said:

    @Mason Wheeler said:

    @boomzilla said:

    @Mason Wheeler said:
    Why are you consistently conflating "work" with "check code in to source control"?  To me, "work" means "writing, testing, or debugging code," not "checking code in". That's what you do when you're done working on it.

    That's true-ish. It depends on the task. Anyways, if I'm not connected at the point I want to commit, it's a PITA. Sometimes I go a few days between commits. Sometimes just a few minutes.

     

    What does that even accomplish, though? DVCS enthusiasts are always talking about offline commits as if they were some revolutionary Great Thing, but I've never seen the point.

    There are two good reasons to check your code in: to share it with the team/the public, and to have a versioned backup somewhere other than your system, in case your system dies.  Local commits accomplish neither one, so what good are they?  (Not trying to troll here; honest question.)

    "Offline" does not mean that the client is not connected to internet, it could simply be that the source control server is out of reach behind a corporate firewall or a similar situation. So if you have developers that work from home or from various satellite offices it can be annoying because either they have to fire up a disrupting VPN client to commit, or they have to commit less often so they have less tools to troubleshoot or rollback things.

    DVCSes allow you to commit without sharing your changes, so you can finish your work in multiple steps and be able to roll back or remove intermediate steps.

    It also means you don't have a single point of failure if your source control server goes down or loses a drive. No downtime, just keep on working since you have a fully functional clone of the repository on your machine.

    check this out



  • @Ben L. said:

    DVCSes allow you to commit without sharing your changes, so you can finish your work in multiple steps and be able to roll back or remove intermediate steps.

    It also means you don't have a single point of failure if your source control server goes down or loses a drive. No downtime, just keep on working since you have a fully functional clone of the repository on your machine.

    check this out

    Branching in Git is not more advanced than in other products, and this basic concept can be explained it without retarded animations and graphics.



  • @Ronald said:

    @Ben L. said:
    DVCSes allow you to commit without sharing your changes, so you can finish your work in multiple steps and be able to roll back or remove intermediate steps.

    It also means you don't have a single point of failure if your source control server goes down or loses a drive. No downtime, just keep on working since you have a fully functional clone of the repository on your machine.

    check this out

    Branching in Git is not more advanced than in other products, and this basic concept can be explained it without retarded animations and graphics.

    You've either never used git or never used svn. I can guarantee this.



  • @Ben L. said:

    @Ronald said:
    @Ben L. said:
    DVCSes allow you to commit without sharing your changes, so you can finish your work in multiple steps and be able to roll back or remove intermediate steps.

    It also means you don't have a single point of failure if your source control server goes down or loses a drive. No downtime, just keep on working since you have a fully functional clone of the repository on your machine.

    check this out

    Branching in Git is not more advanced than in other products, and this basic concept can be explained it without retarded animations and graphics.

    You've either never used git or never used svn. I can guarantee this.

    I was using SVN when you were still living with your mom I was using SVN back in the days were long curly hair were cool ... well I have a hard time finding a reference that a fat young Al Yankovic living with his mom could understand, so let's just say I've known Subversion since before the first service pack of Windows XP was released (that's the Windows before the Windows before Windows 7) and I've had the displeasure of dealing with Git since years before you joined this forum.

    I find your Git enthusiasm endearing but it's nothing new. You see there was a time where Subversion was bleeding-edge and the same fucking shit that goes on with Git zealots happened back then, only it was "SVN is better than CVS" and "SVN makes it easier to branch than CVS" instead of "Git is better than SVN" and "Git makes it easier to branch than SVN". And instead of getting their rocks off talking about offline commits like Git new converts, the SVN new converts were babbling about repository-wide versioning. But already the Git hype is getting cold, it's been out there for a while.

    But guess what, the tool does not make the carpenter, and to this day my client who is the most effective with release management and source control is using WinCVS, which is a truly horrible product:

    I'm not bothered by your Git fanatism however, because I know that you will ditch that piece of shit whenever something cooler makes it way to the backwaters of Wisconsin. Maybe fossil? Who knows. Kids these days.



  • @PJH said:

    @toon said:
    Back to source control. It was implemented by the age old strategy of "there's a network share over at address X, try not to fuck up too badly". I
    Out of interest, what was to stop you implementing source control yourself somehow? Granted you'd be the only one using it, but you'd have at least some sort of (incomplete) history, even if you took the "check in any changes before I start changing stuff, check in any changes after I've changed stuff," just to catch what they've changed in the interim.

    Not thinking of the possibility, that would be reason #1. Not being familiar with version control system myself at that time, would have been reason #2 (but that's no excuse, as I've pointed out before).

    Also, I think they would have found out somehow and gotten paranoid. Maybe I would have been able to show them that by being able to track changes, I could be the hero of the day by allowing them to for instance revert that find/replace thing. But I think it would have aroused more negative effects than positive ones if they found out about that somehow: this is probably my slightly bitter ex-employee sentiment talking though.



  • Ronald, I don't even

    @Ronald said:

    Branching in Git is not more advanced than in other products, and this basic concept can be explained it without retarded animations and graphics.

    First of all: the whole point of the way Git branches is that it's supposed to be less advanced: they made it as stupid and simple as they could. That's a good thing. Branching and merging is much of what makes VCS great and it should not be rocket science. Also, you say your link explains branching without animation or graphics, except your link does not talk about branching and it does it with graphics. All you're proving is that you can post a link to a page and completely fail to understand what that page talks about. You're a software developer, man: you should be able to understand stuff!

    @Ronald said:

    I was using SVN when you were still living with your mom I was using SVN back in the days were long curly hair were cool ... well I have a hard time finding a reference that a fat young Al Yankovic living with his mom could understand, so let's just say I've known Subversion since before the first service pack of Windows XP was released (that's the Windows before the Windows before Windows 7) and I've had the displeasure of dealing with Git since years before you joined this forum.

    So you're old: that's easy, and it's nothing commendable: all you have to do is not die, hell even Gary Busey can do that. You're calling people names: that's also easy, and it's unconstructively negative, so it makes you look like an asshole. None of that is any argument against Git. I remember working at a big telephone company, and I was having a discussion about telephony with a coworker, when he suddenly goes: "I've been working here for thirty years, you know" as if that's supposed to make me go: "ah yes, I can see why that would make this problem be on the user's end instead of in the line now". I could never take him seriously after that. You're being that guy right now.

    @Ronald said:

    I find your Git enthusiasm endearing but it's nothing new. I can't make a point without being patronizing and sarcastic

    FTFY

    @Ronald said:

    You see there was a time where Subversion was bleeding-edge and the same fucking shit that goes on with Git zealots happened back then, only it was "SVN is better than CVS" and "SVN makes it easier to branch than CVS" instead of "Git is better than SVN" and "Git makes it easier to branch than SVN". And instead of getting their rocks off talking about offline commits like Git new converts, the SVN new converts were babbling about repository-wide versioning. But already the Git hype is getting cold, it's been out there for a while.

    All you're saying is: "all these kids today are saying that Windows 7 is better than Windows XP, well I remember when kids were saying that Windows XP was better than Windows 95". Well, how does that make Git worse than SVN? It doesn't. Apart from that, you can do repository-wide versioning with Git, which, having been designed from the ground up to do that, is much better at it than SVN. Also, if Git makes it easier to branch than SVN, doesn't that make it better, not worse, than SVN when it comes to branching? I'm not saying Git is better than SVN, I'm just saying you're doing a very poor job in trying to prove the opposite. I'm not arguing against your point that Git is hyped, I'm just saying that being hyped doesn't make something bad per se.

    Look back at this thread, you say Git is a piece of shit, you're backing it up by paying it compliments, and now you're being a dickhead to Ben L. for actually getting it the right way around instead of screwing it up.

    Finally:

    @Ronald said:

    But guess what, the tool does not make the carpenter, and to this day my client who is the most effective with release management and source control is using WinCVS, which is a truly horrible product:

    Yeah, well my grandfather used to do actual carpentry as a hobby, and he never used any power tools. The tool does not make the carpenter, and maybe if he had owned power tools, he'd still have stuck to his trusty old tools. But does the fact that my grandpa could sand a block of wood perfectly without a belt sander, mean that sanding is just as easy with a bit of sandpaper as with a belt sander? Because that's the point you're making. If you ask me (which you're not): you want to do professional carpentry full-time and sand lots of wood, get a belt sander and thank the sanding gods up above for their gift to mankind. If your client wants to use horrible software, that's on them.



  • @toon said:

    If your client wants to use horrible software, that's on them.

    No they don't "want" to use WinCVS, it's just that the existing system works and so far nobody has been able to build a business case that would warrant replacing it. They have 11 LOB silos and somewhere between 50 and 60 developers, yet they run two totally automated builds every day and from the manifest that is provided automatically with each change proposed to the weekly CAB it's possible to pinpoint exactly which people in the organization would be impacted if the deployment was a failure. It's a magnificent system but of course every once in a while a new developer comes on board and tries to peddle this magical thing called Git. But exactly as it happened in this thread the actual benefits of switching to Git are always vague and filled with empty buzzwords, and a migration would solve no significant problem for the organization anyways.

    About Git: I think that DVCS is the way forward but I also think that Git specifically is an abomination that does not deserve the glowing praise it currently receives. Source control should not be something that is time-consuming enough to show up in the timesheet of a developer, yet in any organization where that horrendous sack of shit is introduced within weeks it's usually a line item in the WBS reports. Compare that to proprietary solutions like Perforce or TFS which have not only more features but are also far less tedious to use, and it's obvious that introducing Git in an organization is basically sabotage. Did you ever try Repo? That's two notches below waterboarding on my list of things I enjoy.

    Git is basically a big joke that is used mostly by people who publish broken jquery plugins on github (and frequently fuck up their own releases), and by college kids who designed RoR websites connected to Couchbase running on a small gear at redshift so their moms could keep track of her church activities using a javascript/html5 calendar. Between them and the people who maintain the Linux kernel there is a huge no man's land where Git has probably caused more lost productivity than internet porn and facebook together.


  • Discourse touched me in a no-no place

    @Ronald said:

    Git has probably caused more lost productivity than internet porn and facebook together.
    Hyperbole much? Git's not perfect, but it's far better than so many of the alternatives as long as you accept the model. That model? Everyone works on their own branches. Where it starts to suck in workflow terms is when you've got people who want to work on the same branch; the subtleties of branching and rebasing are non-trivial, yet everyone has to understand them if they're going to work on a common branch. (The learning curve for git also has some horrible inflections in it.)

    But subversion is pretty nasty in other ways, particularly in the way it is far too easy to do tags within branches within subdirectories within branches. That's just awful. (The problems with speed and needing to be connected, and the horrible mess that happens when you're doing a non-trivial merge, those are the icing on the cake.)



  • @Mason Wheeler said:

    @boomzilla said:

    @Mason Wheeler said:
    Why are you consistently conflating "work" with "check code in to source control"?  To me, "work" means "writing, testing, or debugging code," not "checking code in". That's what you do when you're done working on it.

    That's true-ish. It depends on the task. Anyways, if I'm not connected at the point I want to commit, it's a PITA. Sometimes I go a few days between commits. Sometimes just a few minutes.

     

    What does that even accomplish, though? DVCS enthusiasts are always talking about offline commits as if they were some revolutionary Great Thing, but I've never seen the point.

    There are two good reasons to check your code in: to share it with the team/the public, and to have a versioned backup somewhere other than your system, in case your system dies.  Local commits accomplish neither one, so what good are they?  (Not trying to troll here; honest question.)

    It may be that part of the disconnect here is that the meaning of "check code into source control" changes in a DVCS.

    If the system is centralized and lockstepped, "check code into source control" is synonymous with "propagate your work to the other developers." In DVCS, a local commit doesn't expose your work to everyone else, and while it is often discouraged, in several of the distributed solutions you can modify your local commit history before you make your changes generally available. The equivalent thing that you do "when you're done working on it" is push the changes out to where other people can get them (often after merging or rebasing your local micro-branch).

    In that context, it becomes a lot more appealing to make a local commit for very minor changes, possibly just to keep your place...which adds a third good reason to check your code in, at least locally: To have a history of your progress on the bit you're implementing, so if you realize you took a wrong turn in your approach midway through, you can easily roll back to that point and resume. It kinda turns into a commented local history, or a complete-thought-level "undo" stack.



  • @Ben L. said:

    @OzPeter said:
    @Ben L. said:
    @toon said:
    And you could set up different repos

    Having one repo for multiple projects is TRWTF

    I've yet to see any simple methodology as to how you share source code between projects in things like Git, e.g. A header file full of defines that are used in matching client and server projects. Sure VSS has its faults (and I know them backwards) but sharing code between projects was dead easy.

    You mean like Source engine mods? Because I'm pretty sure any client/server program that shares code is a single project.

     

    Last I heard, Valve uses Perforce internally and Git for anything [url=https://github.com/ValveSoftware/source-sdk-2013]public facing[/url], but the latter may just be because Perforce can export to git and they wanted to use GitHub's issue tracker.



  • @boomzilla said:

    @Mason Wheeler said:
    Have any of the people hating on SVN in here actually used it recently?  Because to those of us who have, the complaints look laughably outdated.

    I wasn't hating on svn in this thread, but it still has a fatal flaw, which is that it follows the merge-on-commit paradigm (which is OK if you're a team of one) instead of commit-then-merge. There's also the fact that you have to be able to connect with the central server, which is a severe to fatal flaw depending on the way you work. I haven't done a lot of merging, but it still seems more difficult than it is in hg, which is the DVCS I'm most familiar with.

    It could be worse.  It could be git where you can't pull a branch if you have changes to one of the files it modifies unless you stash said file first.  Even if a merge wouldn't affect the part of the file you've modified.  Then there's the fact that git's revert seems to work differently than everyone else's revert (you can't revert local changes, only committed changes) where it's easier to just delete the file and issue the pull command again...

    Speaking of commit and merge, git leaves an annoying message in the history about auto-merging when you finally do push commits back to the central repo under the commit-then-merge paradigm.

    Of course, Mercurial  manages to side step some of these problems by making you have to pull then update your working copy instead of making it a single-step process.  Which causes problems if you forgot to run the update command like I have in the past and wonder why you still have problems already committed to the central repo.


  • ♿ (Parody)

    @powerlord said:


    could be worse.  It could be git where you can't pull a branch if you have changes to one of the files it modifies unless you stash said file first.  Even if a merge wouldn't affect the part of the file you've modified.  Then there's the fact that git's revert seems to work differently than everyone else's revert (you can't revert local changes, only committed changes) where it's easier to just delete the file and issue the pull command again...

    Speaking of commit and merge, git leaves an annoying message in the history about auto-merging when you finally do push commits back to the central repo under the commit-then-merge paradigm.

    Of course, Mercurial  manages to side step some of these problems by making you have to pull then update your working copy instead of making it a single-step process like every other VCS on the planet.  I won't even go into how many times I've forgotten to issue an update after pulling simply because no one else makes you do that.

    I haven't used git in a nontrivial manner. I really like the way mercurial handles anonymous branches. Looking at what git stash does...I don't really have a problem with that. It's still better than having something like svn fuck up your work before you can commit.

    The need to update after a pull in mercurial is annoying. A sensible behavior would be to automatically update to the tip of the current branch if you have no uncommitted changes. I've gotten burned by that, too.


Log in to reply