On 5/12/07, Rick Faircloth <[EMAIL PROTECTED]> wrote: > Boy... and to think I was really looking forward to reading this long > thread, hoping that, as I contemplate implementing Eclipse, CFEclipse, > and Subversion, that I would be able to confidently set up a new > working environment... but alas, all this thread has brought is confusion.
Setting up the environment is pretty straightforward -- heck, you can start by installing the svn command line _right now_ and using file:/// to access local repositories without even configuring a server. There's no reason to delay getting the environment set up b/c of confusion about what I'm going to label *process*, which is what a lot of this thread is about. > It seems almost all perspectives offered in this thread revolves around > team environments. The fundamental use of the tool is the same -- Subversion stores files and the delta of each committed change. That's pretty much it. It doesn't care about builds or tests or teams or solo developers or deployments or web applications or programming at all. All Subversion knows about is files and the changes to a file or set of files between commits. Pretty boring work that is well-suited to a machine :) The rest of this is about how to take that tool and use it to manage a development process, and there's a lot of variations there as the thread attests. If you're specifically interested in Subversion, IMHO the best book out there is Pragmatic Version Control w/ Subversion from the Pragmatic Programmers. I'm teaching a course at CFUnited on some of the core open source tools that can be used to build these processes -- Subversion (version control), Ant (builds), and Selenium (web-based functional tests). And I've done some consulting solely on practice for some ColdFusion shops over the past five years. The one key thing I've learned from that is that analysis-paralysis sets in with implementing any development process, just like the inevitable "which framework is best" discussion. In most cases, there are a lot of viable choices and simply starting with a choice is a good first-foot forward. The simplest solution for Subversion in practice is concurrent development in the "trunk" using tags for releases and branches for parallel development. Note that I said both "simplest" and "for Subversion" -- other source control tools have other best practices. Also note that there's issues of scale, procedure, and a myriad other details that can be tailored to best meet the workflow of the project/group in question. A lot of the back and forth about testing, which certainly part of agile development, misses part of the point of version control -- it's about controlling versions of files, no more and no less. Since meaningful comments are an important part of any commit message, my threshold for checking in something relates to the story being told by the comments about the app. I see all to much "fixed bug" or "made some changes" or "todays work" as the comment in a svn log. What the heck does that mean? I'll check in 3 separate 1 line changes to a CSS file if each one is stand-along, because I want to control the *versions* of the file -- putting in all 3 with one commit means that all three get rolled back together, which is fine when they go together and not fine when they don't. > As a sole (as in the only developer on my projects) developer, the question > remains, what would be the be approach to Subversion for me? Use it to store changes to your files, no more and no less. I'd get the Pragmatic Programmers book as a starting point and try whatever is simplest that best matches how you want. The beauty of version control is that you can general change it on the fly. You can start working in a project that looks like this /project and just get moving. When you release it's time for a release and you want to tag the release, you can just use svn to REARRANGE THE REPOSITORY -- yes, it's not cast in stone. It's a tool that stores files and deltas/changes to them. No more. So a couple of svn copy and svn creates later /project/trunk /project/tags/REL-1.0 and so on. Need a branch? Add it. Find that branches are a pain? Get rid of them. It's just files to Subversion. And since the repository is stored very efficiently (at least for text) there's no need to worry that much about space. And if you DO have a lot of binary files, then we can get into fun stuff like svn:externals and the rest of the cool stuff. I'll also suggest that anyone, team or solo, confused about Subversion and the various build/deploy tools should come to my class at CFUnited :) We'll cover this and a lot more. Tuesday, all day, at CFUnited 2007. > Remember, after about 9 or 10 years of development on CF 4.5 without > upgrading > (going to CF8), I'm very comfortable with developing on my *production* > server, > which would cause most of you to pull your hair out in a team environment... Seriously, it makes me pull my hair out in solo dev as well -- how do you roll back? How do you deploy to a new server? Version control is going to help this no matter what. > Rick > > > -----Original Message----- > From: Andrew Scott [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 12, 2007 1:19 AM > To: CF-Talk > Subject: Re: Subversion Tutorial Posted > > Jamie, > > When I talk about build, I am in no way calling it a revision. Its a > version... Thats why so many people do not understand subversion, they treat > it as a revision control system instead of a version control system. > > Now as I also said and have blogged, Eclipse has the ability to revision > your changes so why not use it for what it was designed for. That is why I > say local backup of developer machine, because we use eclipse and we use the > revision that eclipse uses for local machines, and treat subversion as a > version control system that has the ability to roll back to any version > (revision past) we choose to. > > Our java guys (lead by an ex project manager from ebay) will frown upon > anyone who uses branches for revisions instead of versions. So being taught > by someone with so many years experience in this field is a plus on my part. > > As Jamie has indicated, there are many ways to skin the cat. but as I > mentioned downtime costs money, so if you make it as efficent as possible > then why is so hard to adopt? > > It is a very interesting subject, and many developers are going to do things > different. But hey all I am saying as I have pointed out many times in the > past, there are times when downtime is created if all developers work of the > same code, or the trunk is not the most stable build in history, But I > should also be able to go to a branch and know that a version there is going > to be stable too. > > I am in the process of blogging this in more detail, so that people might > understand that branches are not revision controls but version control > system as well. it might surprise you how a simple approach can make all the > difference in the world. > > but lets put this into perspective even more. > > At version 1.3 I had a new client who wants to use our CRM system, but they > want to make subtle changes that are only specific to them. So what does a > developer do? They branch the code at the point that is required and they > now have 2 branches of code they can maintain. > > So what this means is this, I can make changes to the branched code and know > that this version is always going to be specific and is not part of our main > (trunk) development and our developers can continue with both branches at > anytime by switching (in eclipse: team->switch) and they are now editing the > other branch. > > So how can this get messy... Easy, if we use Jamies and most other peoples > approach, we can have 16 different revisions in the branch because the 16 > developers we have could all be working on it at any point in time. > > I would not want to be the one to merge 16 different branches back to the > main trunk, I would prefer to merge one set of code and one set of code > only. Why over complicate matters even more, and this again is time that can > be best spent elsewhere... > > I know a lot of people will disagree with me, and thats fine. I am the > typical developer and I mean typical developer... I am lazy, which means > that if there is a better way to do something and its not going to waste too > much of my time then I go for it. > > Now most people are going to say, but why not use 2 different repositories > for the two different clients. Well that is answered in the Subversion > manual itself. If you read the chapter on branches, it clearly states why > branches are important and what they are for. > > But like I said, if you want to waste time by having to sit down and merge > code from 16 branches to the main trunk instead of the developer merging > their code into the trunk... So be it... And then if you ever have to > maitain what branches are there for 2 different versions of code for 2 > different clients, and you have 16 other revisions to please your > development process I can see a very messy repository. Not to mention how do > I know what branch my developer, needs to go with what version for what > client. > > Enough said, at the end of the day you all need to work out what is more > important your time or wasting it. And Jamie I am sorry to say your's is > another case of how to waste the clients money and your time and over > complicate the matter even more. > > > > On 5/12/07, Jaime Metcher <[EMAIL PROTECTED]> wrote: > > > > I don't reckon this thread is long enough yet, so here's some more... > > > > There are so many ways to use Subversion that it's easy to be in violent > > agreement. We all agree on this: > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:277998 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
