[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 02:16:10 CET

Daniel Noll wrote:
> Byron Brummer wrote:
>>> *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?
> Nope:
> Create a branch, i.e. this version is now "stable."
> make a fix on the branch, sync to server.
> make a fix on the branch, sync to server.
> ...

        To show the complete reality this must be changed to:

        Create a branch, i.e. this version is now "stable."
        make a fix on the branch.
        push fix to qa
        make another fix on the branch (first still in qa...)
        first fix failed qa, but doesn't break anything else
        push second fix to qa.
        second fix passes qa...but first didn't...now what?
        pull first fix from qa
        run full regression on qa which now only has the second fix.

        Your model makes the assumption that anything checked in by
        a developer automatically "works" and thus anything else
        can be piled on top and keep going forward. In the real
        world even if the change *does* work *exactly* as everyone
        intended, there are a ton of other reasons it may need to
        get pulled back. The design team didn't like out it looked
        when they finally saw it, the legal department has an issue
        with it, some contract that was in the works failed to go
        through and it legally *can't* be put in production yet (or
        maybe ever, but ya don't know). Etc, etc.

        In short, the real world is not serialized nor predictable
        enough to create perfect branching. The real world needs
        to be much more dynamic and pragmatic. Take the above
        situation and add *hundreds* of issues being fixed at once
        and your serialized model breaks down as it implies that
        anything that didn't pass qa is a blocker for going forward
        on any other fix. It implies only one person can fix anything
        at once. Fine if you're the only dev, not so fine if you're
        one of dozens on the project.

> In the meantime new feature development is happening on the trunk, which
> by definition is not guaranteed to work as a whole, not even per file. ;-)
> This may not be as nice if you want to check out "version with bugfixes
> A and B but not C", but it's good for this sort of small-fix scenario.
> If you did for some strange reason end up wanting a strange combination
> of bugfixes you could probably do that by asking for a specific revision.

        Ding Ding Ding! Exactly. That's called a mixed revision in SVN
        speak and it's intentionally supported for just this reason.

> I fail to see why you make this assumption about my development cycles
> when I haven't even mentioned the kind of work I do.

        Because you're advocating processes that imply significantly larger
        overhead then is acceptable to many situations. Thus one must
        conclude you aren't being faced with such situations. And really,
        that's fine; We all have our own unique needs.

        What I have a problem with is your assumption that what works for
        your environment will work for mine, your implied assumption that
        life over here couldn't possibly be as dynamic and large as it is.

> In case you actually care, my work is around 90% web application and 10%
> common code. For the web applications I generally keep two active
> branches - stable and the trunk. The stable one I manage as previously
> discussed -- make a change, commit it, sync it to the server. It has
> worked for some time now, actually...

        What's the size of these apps? How many developers? How many
        business users driving the process each with their own priorities?
        What industry? Out many outside contracts (not contractors, but
        rather company partner obligations)? I'm getting the idea that
        we've got very different prospectives of scale on the subject.

        But really, what does it matter? The real idea is to have options
        which allows each user to use the tools in the way that best gets
        *their* job done.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 02:17:14 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.