Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday June 22, 2009
07:10 AM

Tight Coupling of Applications

[ #39161 ]

At the BBC, we have some mandated technology stacks. While this is almost galling to some people's interpretation of TIMTOWTDI, the reality is that in a large-scale environment, it's very helpful to admins to not have to worry about which VCS, Wiki or other tools teams are using when needing different teams to work in shared environments. Of course, when you get down to lower level stuff, you really don't want to tell a team they can't upgrade DBD::mysql because another team requires an older version, but compromises have to be made. Today, that compromise is becoming painful.

I recently tried to commit some changes to our architecture dependent CPAN modules (for example,modules in deps/lib/perl5/i486-linux-gnu-thread-multi/). However, subversion kept insisting that a bunch of files I was adding already existed in the repository, even though svn ls svn://path/to/archdeps did not list those files. After I and another developer kept digging around, we finally gave up and came up with a work-around. First, I did this:

find . -type d -name '.svn' --exec rm -fr {} \;

I then tarred up the deps directory, made a fresh checkout and untarred the files over the fresh checkout. The commit then worked just fine. Unfortunately, I then found out that somehow this corrupted several XS extensions, forcing me to reinstall them. Luckily this was trivial, but the last time this happened (yes, this has happened before!), I couldn't even run the cpan shell due to corrupted XS dependencies.

Having run into numerous issues with Subversion and having found git to be so pleasant to work with, I thought it was time for us to give up and switch to git, but we can't. Even if we get developer buy-in, we use Trac. Trac is tightly integrated with subversion but not with git. There are git plugins for Trac, but they're not ready for production use. Even if they were, it shouldn't be the case that two developers dealing with a frustration invest a lot of time and money into solving a problem whose solution potentially impacts a number of other teams.

The fact that Trac is so tightly integrated with our subversion use of Subversion is a huge frustration (I don't know enough about the internals of Trac to know if this is our fault or theirs). I'd love to find a better way of dealing with this and I'd be ecstatic to see some strategy for decoupling the two. Unfortunately, it's not going to happen.

There are some great benefits of working with larger organizations, but this ain't one of them.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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 []). 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