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
change.
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
workstation.
> 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.
-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 01:08:56 2007