Eric Siegerman wrote:
> I'd rephrase "there should be no need" to "depending on your
> process, you might be able to get away without it".
I wouldn't. But I will concede that most of the industry has
accepted standards of work in software that could be vastly improved
upon, and my "should" is based on standards higher than those. Or
perhaps I just need to think about it some more to see those problems
I'm not considering...
However, this little exchange has raised an interesting problem for
me. Actually, I've bumped up against it frequently lately, but this
is the first time I've looked at it from a project management
perspective. Let's call it the "Pandora's Black Box" problem. A
developer starts working on an issue (bug, feature, etc.), then
decides (after gaining more knowledge of the inner workings of the
project) that it *may* be appropriate to take a different tack on the
matter. What does she do now? Backbranch(!? - just branch?)) and
checkin the WIP from the first attempt, then start the second in a
clean sandbox? Leave the (possibly fragile as the main branch
evolves) WIP idle and come back to it later (note the DR hazard)?
Does anyone have a method in place for dealing with this? I'd be
interested to hear...
/|/|ike
P.S. Yeah, I guess it's OT...sending anyway ;-)
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
