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.
-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 02:17:14 2007