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.

Subversion layout advice needed 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Possibly a silly question - but do you need the alpha/beta/gamma level at all? Why do you need the development team breakdown explicit in the repository? Won't that make things harder if modules move between teams?

    Curious...

    • The concern is that the various code bases are wildly divergent, but with extremely similar names (e.g., ControlPanel), that it would be confusing. The long term goal is to merge what we can.

      • Ah. Okay.

        In that case I think it depends on whether you think you're going to be tagging/branching all of a teams work (in which case you want your first layout) or tagging/branching on a per-module bass (in which case you want the second).

        The first layout also allows you to checkout an entire teams modules in one go, where with the second you would have to check out each trunk individually. I guess you could use svn:externals to get over that.

        Since you're planning to merge I'd probably go for the second, s

        • Well, I don't the target is to completely eliminate those distinctions. It's to have common infrastructure code that we can all share, but we'd be keeping our overall code bases separate.

          • If you want to keep you alpha/beta/gamma codebases separate, then consider:

            svn://svn.example.com/alpha/trunk/...
            svn://svn.example.com/beta/trunk/...
            svn ://svn.example.com/gamma/trunk/...

            It allows each team to check out their entire repo, which is a good thing. It's also equivalent to the situation where you're not three teams under the same roof, but three teams in three different organizations periodically sharing code amongst yourselves:

            svn://alpha.example.com/trunk/...
            svn://beta.example.com/trunk/.

  • While it's a different situation, when I was setting up my CPAN repository on googlecode, what I thought about was how I (or others) would use SVK to work with the code. What parts of the repository would I mirror locally?

    Putting the trunk too high up would mean I'd be mirroring everything or else having to separately mirror a trunk, tags, and branches if I only wanted to work on a single module.

      /svn/trunk/{module-A|module-B|...}
      /svn/tags/{module-A|module-B|...}
      /svn/branches/{modul

  • I've used option 1 and ended up having a big rename to option 3. I ended up with a huge tags directory full of unrelated stuff, which was really irritating. Keeping the branches and tags for each module related was much more useful.
    • I agree, one should be able to rapidly find what one is looking for, and if I'm working on Module::One I would not be happy to look for its tags among those of Module::Two, etc.

      I usually go for the 2nd option, but mainly because I write few modules for very separated projects. One comment above points out that 3rd option can be useful to check out the complete bunch of stuff for one's group, that could be cool. OTOH, I'd still stick to a solution in which the module name comes before its variants:

      {alpha

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.