[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion tagging

From: Byron Brummer <byron.brummer_at_livenation.com>
Date: 2007-01-22 20:49:34 CET

L. Wayne Johnson wrote:
> I'll admit that I don't understand this use case, maybe because I only use
> svn for source code projects (all the things under source code control work
> together.)
>
> If all the files work together it not clear to me how you can
> know the 'quality' of a single file in the collection since they are all
> interrelated. And even if you can there is no guarantee that the file will
> do what you want when matched up to files of a known 'quality' from a
> different time. To me, the quality of a single file just doesn't count. My
> customer doesn't care whether or not foo.c works correctly or not. My
> customer only cares that when he runs my software he gets the "right
> answer."

        Your term "source code projects" is a bit broad. The lifecycle of
        a product intended to be shrink wrapped is *drastically* different
        from that of a web based app or internal company app. Yet they
        are all "source code projects".

        Your bias here appears to be toward the shrink wrap lifecycle (as
        are most (misnamed) "best practices" SCM guidelines). A typical
        modern web app doesn't naturally follow anything remotely close
        to that lifecycle.

        Other paradigm like XP and OOP can quickly show problems in the
        "standard" shrinkwrap model as well, but for different reasons.
        For XP branching much or at all is counterproductive to the
        practice ("shrinkwrap product" or not) as it pushes integration
        down the road. For OOP the modularity of the code base can often
        mean that changes are so isolated that yes, the status of small
        chunks of the tree matters independently as well as a whole.

> The original poster asked for a way to pick a bunch of files from different
> times in the source code development without having to go pick them all one
> by one. I don't understand how you can pick a bunch of unconnected things
> without picking each one by hand.

        cvs rtag -r OLD_STATE NEW_STATE my_module
        cvs rtag -F -r HEAD NEW_STATE my_module/bump_this_file.txt

        The result is NEW_STATE is everything OLD_STATE had, plus one file
        updated. A common use case is that OLD_STATE might be QA_BUILD_4
        and NEW_STATE would be QA_BUILD_5.

> Subversion doesn't keep track of files, it tracks groups of files.

        And a CVS style tag *is* a labeled group of files (and revs). It's
        much the same as if you used copy in SVN from a WC to a tag/my_tag,
        just much saner for anyone looking at the file's history. In SVN
        when you create one tag from the location of another you're really
        screwing the hell out of the file's history. It's very easy to
        end up look at a tag/release_1.2 tagged file and finding you need
        to recursively lookup it's ancestry *HUNDREDS OF LEVELS* to find
        the *actual* home of it:

                rel_1.2 (copied from build_425)
                build_425 (copied from build_424)
                build_423 (copied from build_422)
                ......
                build_15 (copied from branch/branch-1.2)

        SVN does a great job of tracking the current state of the universe.
        Where it fails badly is tracking any other status besides latest
        and far worse still on reporting history (especially summary history
        from one state (say, qa build) to another. It's a huge drawback
        for most any modern web based application.

        Another use case for real status labels is in managing the merge
        process. CVS tags work great for tracking the state of merges
        including partial merges. -In a large app it's not uncommon for
        a major merge to take a while and be done in logical chunks. CVS
        tags allow you to mark the state file by file or directory by
        directory as you progress through the merge.

        Code reviews are another great use for status labels, again because
        you're rarely able to review the entire tree in one shot. Labels
        in this use form a kind of book mark.

> It seems
> to me that this was a conscious design decision and that with source code
> projects, this is what you really want to do. I am not an expert in how svn
> works but from what I understand it seems that adding support to track files
> individually would be difficult at best.

        Actually it'd be trivial, at least functionally. Unversioned
        properties is the obvious location for this information and that's
        already in the SVN filesystem).

        The real issue would be performance. SVN does what it calls "tags" the
        way it does not because CVS tags weren't functionally a very useful
        feature, but rather because such per-file-rev state tracking is a
        major performance hog. Instead of being clever and finding a way to
        keep this incredibly useful feature from CVS (and most SCM systems),
        the SVN devs came up with this copy/branch idea. While I'm sure the
        devs thought they were being incredibly cleaver, in reality it's a
        cop out that doesn't actually solve the problem.

        In CVS I can:

                cvs log -r FROM_TAG:TO_TAG my_module

        In SVN I can't. This obvious feature simply is missing from SVN wholesale.
        There is "svn log -r10:20 my_module/branch/some_branch", but this is
        not equivalent in the slightest. Who says FROM_TAG is rev "10" on every
        file? Heck, who says it even is from the same branch? SVN supports
        mixed revision/location tagging and so SVN "tags", just like CVS tags,
        can translate to a collection of files/directories of mixed revisions and/or
        off different branches. In the real world there are many valid uses for
        this which is why both support it. The difference comes in that CVS can
        actually report on such sets (mostly sanely) while SVN can not at all,
        additionally SVN must use a working copy to create such sets which can be
        hugely expensive while CVS allows you to do it all remotely.

        And of course...where do I keep track that "10" and "20" are the revs I care
        about? Some "numbers_that_matter.txt" text file? You can use SVN's "tags"
        again, but with difficulty. -You can't look at a given file and see how much
        of its history has been merged and when (there's no "copied to" support, only
        copied from).

> There are some people that use subversion for tracking unrelated documents.
> I don't think that Subversion was really not designed to do this.

        A configuration is inclusive. If you are only able to track one section of
        a configuration then you are not a configuration management tool.

-Byron

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 22 20:50:46 2007

This is an archived mail posted to the Subversion Users mailing list.