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?
-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:27:56 2007