Les Mikesell wrote:
> Daniel Noll wrote:
>> Byron Brummer wrote:
>>> 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.
>>
>> Maybe it shouldn't have been checked in yet, if the relevant parties
>> hadn't approved it. What I would do in this contrived example is to
>> send the diff to the parties who need to approve it, and if it gets
>> through, then commit it.
>>
> If you think something shouldn't be checked in because it is not
> finalized yet, I
> think you've missed the point of a revision control system where you can
> recall any state you want and review the changes before or after that
> state.
> If anyone wants diffs they can easily generate them. Subversion's tags
> can be used to give permanent names to these states. However, since tags
> are end points in subversion, it is not particularly handy to track a
> file's
> history through many tagged states without knowing which tags to
> compare ahead of time.
Les is complete correct.
If you're going to pass diffs around through the lifecycle then
you need yet *another* system to manage, track, and report on
those diffs, their state in the process, etc. And guess what
SubVersion and all other SCM tools do at their heart? Yep,
they manage, track, and report on diffs.
Just because Linus was a moron when it came to SCM and "tracked"
all submissions via patch files attached to email messages (and
we saw how well *that* worked pre-bitkeeper use), doesn't mean
it's a good idea. It's a horrid idea, as Linus himself proved
beyond a shadow of a doubt to most anyone trying to contribute
to Linux at the time.
-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 22:02:43 2007