[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:26:44 CET

L. Wayne Johnson wrote:
>>>> I really would like to understand here but I can't imagine why you
>>> would
>>>> want to tag something other than what some developer is working on in
>>>> his/her working copy.
>>> Because software rarely is a single machine. More often then not
>>> it's a collection of machines that may or may not talk to each
>>> other at various moments in time. It is invalid to believe because
>>> the radio isn't working that the engine won't start. Sure, they
>>> are both parts of the car, and maybe the changes to the radio were
>>> made first...
>>> But who really cares that the fixes to the carburettor weren't
>>> developed against the old version of the radio? The radio can
>>> wait,
>>> the carb can't.
> I wouldn't care. That's why I wouldn't tie the release of one with the other
> at all. I think that if I had 2 things so different that I wouldn't try to
> associate them in my source code control...

        At the end of the day you're shipping the *car*. The car is the
        configuration, as a whole. You aren't shipping the car in parts.

> Clearly subversion has warts but there are
> several things that just seem right to me.

        Agreed. What were talking about here is a wort. Little gets done
        when all you do is sing the praises of something and shun anyone
        who mentions the worts. -Thus is the problem of the Republican party,
        but that's another thread. ;-)

> 1.) Atomic commits. This allows me to add a feature or fix something and
> check in *all* the changes at the same time. Some times this involves a
> single file but sometimes it takes more than one. Either way I know that the
> changes in between revision x and revision y contain *all* of the changes
> required to address feature/bug n.

        In an ideal world...sure.

        In the real world you'll commit this changeset believing that yes,
        it contains all that's required for this particular fix. But then
        QA gets ahold of it and woops, it didn't pass. So you revisit the
        fix, complete the part you missed, and commit it. The process
        repeats, but now your nice tidy atomic commit is spread across two
        revisions. By the time it actually gets through QA, user acceptance,
        and legal, it may actually include dozens of revisions...

        What would you do instead? Roll back your changes each time and
        try again from scratch so that when it finally passes it would be
        in a single tidy revision?


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:27:56 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.