[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 01:07:45 CET

L. Wayne Johnson wrote:
> I don't think this has anything to do with the "shrink wrap model." I can't
> be sure because I have never worked on shrink-wrapped software. I am not
> sure what XP has to do with it either. It just seems to me that taking
> source files (whether java, html, C, asm or whatever) that are supposed to
> work together from a configuration that never existed is risky.

        It exists the moment you create it.

        Create the abstract collection, then *test it* as such. There is
        no more or less risk then using HEAD of everything. It's much
        like poker: The odds of getting a royal straight flush are identical
        to the odds of getting any other random set of cards. It's the
        human condition that makes us believe the odds change.

        No one advocates moving a single file into production directly and
        thus creating a configuration that never saw time in QA. A change
        to the configuration is a change to the configuration, be it
        a "natural" change to something at the top of HEAD or a selective

        This is in fact *NO DIFFERENT WHATSOEVER* then making a change on
        branch and merging to integrate. Both create a composite
        configuration that never before that moment existed on a dev's

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

>>> 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.
> This is the goal; however, in practice this often fails. Assumptions creep
> in and subtle bugs are missed. That is why you have unit tests and
> integrations tests. Then if you run the unit tests before you check your
> code in you can at least be sure that the things that you thought of work
> correctly. In turn it's more likely that your isolated changes don't break
> something else.

        Agreed. Which is why you test any composite configuration created.

        Again, such composite configurations are *no different whatsoever*
        from those done using branches. In both methods you are still
        creating a new, composite configuration that never before existed.
        It's a new configuration that must be tested as a complete unit.

> I guess I should have been a little clearer in my original post. I am not
> really trying to dump on someone's process. I hang out on this list for 2
> reasons. 1.) I use subversion (my company does not) 2.) I want to understand
> how people are using subversion.
> Everyone at my company agrees that our current version control system sucks.
> I would (and have) suggested converting our vcs over to subversion but it
> doesn't fit with the way that we currently do things. I would ask for
> subversion to be changed so that it fits our current work flow but I think
> it would be better to fix our work flow. The current process takes hours to
> just release a build for testing. That may not seem that bad but I am only
> taking about a 700k binary that takes 15 minutes to check out and build ...

        Never let your tools drive your process. The process is 10x more
        important then the tool that implements it.

        Design a process that works with your product's lifecycle, business
        needs, speed, risk, etc. *Then* use what tools you have or can
        find to implement it. Yes, this means rarely will anything "work
        right out of the box". But that's the point: SubVersion (along with
        all other SCM tools) are *tools* to build a solution, they are *not*
        the solutions themselves.


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