[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-23 00:40:11 CET

Daniel Noll wrote:
> Byron Brummer wrote:
>> Sure, you can argue from the ivory tower that the world would be
>> better off doing things the old, slow, lumbering way. But the
>> rest of the world is going to wonder, "You've got a problem on your
>> production system that simply updating this one file will fix,
>> but you refuse to do it without also updating the rest of the
>> entire tree that isn't ready for production. WTF?!"
>
> *Usually* one would do this by fixing the one file on the branch, rather
> than using the trunk for such things.

        Create a branch, make one fix.
        Create another branch, make a different fix.
        Create another branch, make yet another fix.

        Is this the pattern you're advocating? It has advantages wrt
        isolation, but the overhead is huge. Additionally integration
        is pushed down the road, greatly increasing the likelihood of
        issues which again increases the overhead as well as risk.

        Back in the real world we find that 99.9% of changes are small,
        isolated, and don't mingle with other changes happening at the
        same time. Branch per change or similar is to argue that you
        should plan your entire process around the most unlikely of
        conditions (the 0.1% of times you'll clash). -I'm speaking
        with my own bias right now toward web based applications.

        Again, you're in a shrinkwrap lifecycle with a traditional
        process (changes grow more expensive as time goes forward,
        unlike in XP). Much of the world is passing you by.

        In the current setup we've worked out here (live web app,
        frequent updates, fast changing priorities) we don't use a
        "trunk" at all. We develop and release off cascading branches.
        But that's for "major" revisions. Interm "hot fix", "point",
        "bug fix", whatever you want to call them releases are (as they
        must be for sanity) file by file, rev by rev, hand selected.
        With a dozen QA builds a day and multiple production releases
        a week, the old style "merge to an integration branch" model
        just falls flat on its face: You gain no real advantage while
        creating a tracking nightmare.

        SVN is actually built to do this *intentionally*. But the
        design they chose for it is not ideal from a functional
        perspective. CVS does it far better. SVN's design however
        blows CVS's away wrt performance. -It's not hard for CVS's
        tagging to be so expensive as to become unusable (hours
        to tag). SVN's "tags" are functionally inferior in many
        ways, but regardless of the size of the repo the tag operation
        is always fast (seconds). So no one has the true answer yet.

        The real problem as I see is was that the original designers
        of SVN simply didn't understand how CVS tagging was used in
        practice. They didn't know about or understand the more
        advanced use cases.

-Byron

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 00:41:19 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.