use Perl

• how? (Score:1)

  by schelcj (9254)

  how does switching to git from subversion fix this problem? it seems you brute forced a fix rather than finding the root cause.
  • Re: (Score:2)

    by Ovid (2709)

    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
    • Re: (Score:1)

      by Aristotle (5147)

      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
      • Re:how? (Score:2)

        by Shlomi Fish (918) <shlomif@iglu.org.il> on 2009.06.23 2:29 (#69138) Homepage Journal

        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 database for storing the tree and the changesets, but it's not as complex as you describe.

        With git, though, I still don't understand how exactly its data model works. After reading this document [git.or.cz] and asking some people, I can finally handle the day-to-day operation of git, but I still feel it does a lot of voodoo behind the scenes.

        Reply to This

        Parent

        • Re: (Score:1)

          by Aristotle (5147)

          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