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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I agree, allowing tags to be mutable is silly, but has that actually been a problem for you in practice. I don't recall ever actually modifying the contents of stuff under a tag, and you can always revert it.

    As far as the checkout thing goes, that'd be annoying, but I've never done that either. When I want to make a tag I always operate directly on the repo URI:

    svn cp http://.../svn/Foo/trunk [...] http://.../svn/Foo/tags/2.0 [...]

    Yeah, distributed VCS is probably better in lots of ways, but Subversion works well enough in most cases, and many of the faults people point out seem to be conceptual rather than real.

    For me, the biggest thing I've always hated about svn was its lack of merge tracking, which made using more than trivial branches (ones that might need to merge multiple times) impossible. That's why I first start using svk.

    Nowadays, I'm playing with Mercurial, and I like it. I'm still not sure how it'd play out for a project where we wanted some sort of centralized-ish development (like say, commit emails even on branches, so we can do code review).

    • I updated the code to tag directly in the repo. The obnoxious thing is that now there are two operations: update the trunk with the new release iformation, then tag. It is not atomic. I have to specify what changeset to copy into the tag.

      --
      rjbs
      • Uh, shouldn't you check in the "bump version" change to trunk _before_ you tag said version?

    • I use svnmerge.py, which is a lot like the merge tracking in svk.

      I don't really see the problem with tags. I don't edit them, and I don't ever check out from root, so I don't download any files I don't want.

      My only svn problem that I haven't found a simple solution for is the slowdown when your repo gets really huge. I expect git would handle this better, but selective update/commit commands make it workable for me, just not as fast as I want it.

      • Would you know whether that is "huge" in files, or in revisions, or both?

        I'm arguing against putting many different (unrelated) projects in the same svn repo, and this would be another reason to not do that.

    • I agree. The subversion tagging concept is perfectly acceptable because you can always revert them (using "svn revert" or "svn copy -r"), and changing the contents of the tags is unlikely. There are three similar issues with Perl:

      1. using my/our for constants [perl.org.il] - that's what I use most of the time, because it gives me most of the benefits of Readonly that Damian mentions in his book. Again, I might change them, but it's not very likely, so it doesn't matter
      2. Using a leading underscore for private methods ("
      • And a question to rjbs - I still don't understand why you want to check out the entire Subversion repository. This is usually an indication of poor design. If you want to switch from one branch/tag/trunk to another you can always use "svn switch".

        The code all gets checked out to get an atomic commit-and-tag. Without that, you have two transactions.

        Yes, that's work-around-able.

        It doesn't change the fact that Subversion is a pig or that Subversion's tags are, at best, tolerable. "a tag is a copy" is workable, sure, if you are not crazy and likely to change it. That doesn't change the fact that it's much more annoying than it needs to be. If a tag was name for a revision number, I could check out my "whole" project, which would be the heads of the branches and trunk, and I'd be able to list the tags for quick reference for diffing.

        Subversion makes all this annoying and slow.

        --
        rjbs
      • I might change them, but it’s not very likely

        But what’s the failure mode? More than likely, if you do happen to change a constant, you will probably have mysterious bugs that do not obviously point to the culprit. It can potentially take a huge amount of time to track down the issue. The rationale is the same as with using strict, only more polarised. Therefore, for constants, I have gotten into the habit of doing the following:

        our $ANSWER; BEGIN { *ANSWER = \42 }

        Trying to mutate $ANSWER or a

    • you can always revert it

      Unless you’ve accidentally committed the changes (which is hardly unlikely in a scenario where you’ve changed the tag’s files while thinking you were in some other directory), in which case Subversion likes to make your life as miserable as possible in trying to get that commit to go away.