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: (Score:2)

        by Shlomi Fish (918)

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

          by Aristotle (5147) <pagaltzis@gmx.de> on 2009.06.23 3:13 (#69140) Homepage Journal

          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 commit objects, though they can point to pretty much any kind of object. (In practice, they only ever point to commit objects.)

          That’s it. That’s all. The loose-object repository format can be explored with a text editor and is immediately obvious.

          The packed format is trickier, but ultimately it’s just a kind of tarball containing the loose-object format, metaphorically speaking.

          The rest of the glue that holds a repository together is in the refs/ subdirectory, which contains various tiny text files containing either SHA-1 IDs, or names of other files within refs/. This is where branches and lightweight tags get their names.

          It’s all very much in the spirit of Unix.

          For how this model serves as the basis of a coherent system, I recommend that you watch Scott Chacon’s presentation [gitcasts.com] if you haven’t already. His slides are excellent and he does a really good job of explaining it all.

          Reply to This

          Parent