Hey... Whatever... Its your time your wasting, and your developers time in fixing things. I know how pissed I would be if I need to fix someone elses code to get mine to work when there is no reason too.
But if it works for you, and you like to spend more time than needed and waste your clients money then good for you. Just more of a fool for your client. On 5/12/07, Bobby Hartsfield <[EMAIL PROTECTED]> wrote: > > If you say so... most people would go ahead and get the working piece into > version control regardless of its dependants. Our good practices are > apparently bad to some so we can just agree to disagree. Besides... we all > know how belligerent you get around the time that the pubs open up over > there. ;-) > > -----Original Message----- > From: Andrew Scott [mailto:[EMAIL PROTECTED] > Sent: Friday, May 11, 2007 10:51 AM > To: CF-Talk > Subject: Re: Subversion Tutorial Posted > > No there isn't... The methodology should be the same, write a task, test > it. > Does it pass all unit tests, no then find the problem. Does it pass all > unit > tests. Yes then does it rely on something else to work? No then commit to > the repository. > > This is more important in Team situations but regardless... Good practice > is > good practice. > > Yes then you always have the local history as I pointed out that Eclipse > also has without a repository.. > > > > On 5/12/07, Bobby Hartsfield <[EMAIL PROTECTED]> wrote: > > > > Again, I think there is a huge difference when it comes to versioning > Java > > or C++ applications vs. web apps like CF. > > > > -----Original Message----- > > From: Andrew Scott [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 11, 2007 10:23 AM > > To: CF-Talk > > Subject: Re: Subversion Tutorial Posted > > > > Well said... > > > > There are tools on the java development side that test for build breaks > > against the repository too, and I tell you know any of our Java guys > > submits > > code that will break the build has to put $5.00 in a kitty. > > > > But this is rare as Unit testing provided you have written tests to > cover > > all code, will help in not breaking a build. > > > > CF developers serioulsy have a lot to learn when it comes to development > > and > > versioning... > > > > But Doug, back at you... I couldn't have said it better. > > > > > > On 5/12/07, Doug Bezona <[EMAIL PROTECTED]> wrote: > > > > > > While CF is not a compiled language, the old version control maxim > > "Don't > > > Break the Build" still applies. > > > > > > Commits should represent a logical unit of work, and shouldn't leave > the > > > app > > > in a broken state. Version control is not meant as a backup system, or > > an > > > uber undo function - it's intended as a means to retain a history of > > > meaningful changes to an application's state. > > > > > > This is particularly important in a team environment, when other > > > developers > > > may update their working copy at any time. If a half completed set of > > > changes is committed, then their updated working copy may now throw > > > errors, > > > which causes all sorts of issues and wasted time. > > > > > > It's important to think of it in terms of how a revision may be used > in > > > the > > > future. If I need to pull a particular revision, I should be able to > > look > > > at > > > the history and see, via clear commit comments, what changes were made > > to > > > create that revision, and be fairly confident that if I actually check > > out > > > that revision that it will function. > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 The most significant release in over 10 years. Upgrade & see new features. http://www.adobe.com/products/coldfusion?sdid=RVJR Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:277802 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
