>>
>> Your term "source code projects" is a bit broad. The lifecycle of
>> a product intended to be shrink wrapped is *drastically* different
>> from that of a web based app or internal company app. Yet they
>> are all "source code projects".
>>
>> Your bias here appears to be toward the shrink wrap lifecycle (as
>> are most (misnamed) "best practices" SCM guidelines). A typical
>> modern web app doesn't naturally follow anything remotely close
>> to that lifecycle.
>>
>> Other paradigm like XP and OOP can quickly show problems in the
>> "standard" shrinkwrap model as well, but for different reasons.
>> For XP branching much or at all is counterproductive to the
>> practice ("shrinkwrap product" or not) as it pushes integration
>> down the road.
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.
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. Presumably you test your stuff before you check it in.
I would also assume that something has been properly tested before it is
tagged as well. In fact with XP you write the unit tests before you have
working code. The whole point is that you run the unit tests after changes
and then check stuff in. I still can't figure out how that is possible if
you're tagging something that didn't already exist...
>> 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.
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 ...
---------------------------------------------------------------------
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:50 2007