use Perl

• Is it really a problem? (Score:2)

  by autarch (914)

  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 enou
  • Re:Is it really a problem? (Score:2)

    by Shlomi Fish (918) <shlomif@iglu.org.il> on 2008.10.15 12:07 (#65438) Homepage Journal

    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 ("_my_private_method"). Again, the added benefit of having true encapsulation and permissions in Perl's OO is usually not worth it.
    3. Inside-out objects: again - protecting the programmer from himself. Too much trouble for too little (if not negative gain).

    So I say the Subversion tags concept is perfectly fine. You can always use repository-wide permissions to further protect it if you care about it so much.

    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".

    Reply to This

    Parent

    • Re: (Score:1)

      by rjbs (4671)

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

      by Aristotle (5147)

      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