Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • how does switching to git from subversion fix this problem? it seems you brute forced a fix rather than finding the root cause.
    • These are the sorts of problems we constantly run into with Subversion and trying to narrow down the root causes often involves something along the lines of "subversion is very picky about how you do things and throws a hissy fit when you don't play along." Sometimes it's been a matter of updating subversion, other times it's a bunch of developers throwing up their arms in dismay and giving up finding the actual problem (such as debugging a complicated branch merge which has, once again, gone awry). If th

      • The thing with git is, at its core lies a very simple and easily understandable data model. Once you understand how that works and how git puts it to work, it’s basically impossible to dig yourself into a hole you can’t get out of.

        With Subversion, the internals are a morass of complexity. I wrote a few scripts in my time, eg. to undo broken commits immediately after they were made, but they were trivial in their effects and still involved a lot of cargo cult because the Subversion data model is

        • i think my problem is that i shouldn't have to dig into the internals of the scm regardless how easy/hard it is. if i do then either i did something wrong or the scm did. more often then not i would assume it was me that screwed up.
          • i shouldn’t have to dig into the internals of the scm

            I spent 5 minutes trying to figure out how to phrase my sentiment about this. In the end, the best I can do is this: I prefer Unix over Windows.

            more often then not i would assume it was me that screwed up.

            So in that case, which is better: the VCS whose design is so simple that you can figure out how you dug yourself into the hole, and get back out; or the VCS whose design is so hairily complex that you have no option but to abandon ship?

            Having asked that, let me ask next: will the user make mistakes or not?

            But wait; it’s not that simple. Let me ask another question: in which system is it more likely that the user will dig themselves into a hole – either through their own fault or through the software’s –: one whose fundamental design is very simple, or one whose fundamental design is complex?

            Tony Hoare once said that “There are two ways of constructing a software design…”

            • well i've done a piss poor job explaining myself because i agree with everything you have said. i will come back when i can spit out whats in my head clearly. thanks for your time though.