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

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.
  • The Good News:

    It's SO much easier to work with at a tool and people level.

    Everything has a URI! I've ever been releasing to CPAN by giving PAUSE an upload URI and having it pull the file straight out of the repository. Release tarballs all have URIs.

    You can checkout anon, and then it will automatically change to a user/pass account if needed when checking in. And so on, and so forth.

    The Bad News:

    There are no tags. No really. Tags are implemented by making a complete copy of your project into another directory, and the idea that it's a "tag" is implemented as "policy". That is, it only exists in your head, and there's nothing enforced on the server to make it a tag.

    To make a tag, you use the "svn copy" command.

    There are no branches. No really. Branches are also implemented by making a complete copy of your project into another directory, and the idea that it's a "branch" is implemented only in your head as well. There's nothing enforced.

    In fact, this basically means that you can copy a project, and it becomes a tag... except if you commit a change to the tag... in which case... erm... right! It's a branch now!

    To make a branch, you use the "svn copy" command.

    You see where I'm going here...

    On the plus side, the copying is free on the server. This is used as an excuse for why it doesn't matter than tags and branches are real, like they are in CVS.

    On the downside, the copying is NOT free on the client. So if you use tags and branches a lot, and you project is bigger than 100 meg, forget ever checking out the root of the project, because it's going to download and consume gigs and gigs and gigs of disk.

    In short, forget everything you ever learned in CVS about tags and branches, because in SVN it's a whole different world, implemented in wetware and with no standards.

    However, if you don't use tags and branches heavily, it's an absolute clear win to move to SVN. I've moved almost all of my repositories to SVN now, except for one important one that has 5-10 branches, and over a thousand tags, that would just explode in size if I put it into SVN.

    Think of SVN as a plain versioning filesystem, something you'd build a complete VCS on top of, rather than being a full VCS itself.

    Now SVK on the other hand, that shows a lot more promise. It's just that there's no GUI client (yet) :(
    • I wouldn't worry too much about tags and branches. It's mostly just a question of getting used to how subversion does things... For instance, checking out the root of the project is not generally required. It's much easier to just check out the trunk or branch that you're actually concerned with.

      As to converting tags into branches, yes, this can be done easily by accident. I wrote a subversion hook script to prevent this -- it stops commits going ahead if you're committing to a tag. Shout if you wan