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 ask

            • 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.
        • 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 just such a hairy construction.

          I didn't find the Subversion internals that complex. I contributed some patches to Subversion back at the time, and found the code easy enough to understand and change. Subversion indeed uses a transactional

          • Git is trivially simple internally.

            • The ID of every distinct stored object is the SHA-1 hash of its contents.
            • File objects (which contain the contents of a file) are stored directly as binary blobs.
            • Tree objects (ie. directories) are simple plain text with each line containing the ID, type and file name of a contained object.
            • Commit objects are plain text; they contain a simple header listing the IDs of the parent commit(s) and the root tree object for that commit.
            • Tag objects are more or less the same as commi
      • wouldn't the fact that these are frequent problems point to a problem with the process/procedure of subversion usage? i still haven't seen how git makes these complicated issues any better(granted i haven't used git enough yet.) if git does correct these problems does that mean the SCM was the problem or the usage pattern of the dev team? ps: not being snarky, i actually have ran into the same problems with trac/svn. its a love/hate thing with trac for me.
  • That's the second hard-to-reproduce bug I heard with Subversion the past few weeks (this one being the first [perl.org]). I've never ran into such problems with Subversion - it just works, so it seems very strange to me. If you can somehow reproduce the problematic behaviour on non-confidential, example repositories than I'm sure the Subversion developers will appreciate a bug report.

    Complaining is easy, but actually fixing the problems is more worthwhile in the long run.

    • Why should I put time and energy into fixing a bad technology that, if I have the chance, I'll never use again? OK, so that's a bit unfair, but frankly, I just don't care about Subversion any more. It's that simple. I know that in future positions I'll likely be working on projects where management/developers are too timid to switch to something better than Subversion, so yes, I should care how well it works, but if I could reproduce this problem in the first place, I might actually know what caused it a