I would configure my projects the same way if it was possible to have CFB function that way, but it cannot. It's a bit limited in the way (and location wherein) one needs to set up a project. Basically you need to create the project in your web root, and your web root has to also be your application root.

You can create the project in [some other dir], and create a linked dir into that project which points to your source code, but a bunch of CFB's functionality won't work if you do that.

As Adam has said in your other thread, you need version control software when you collaborate on a software project. It enables each team member to maintain his own version of each file in his own separate sandbox in the 'repository'. He can change any part of his version of the software at will, without affecting the work of others. Eventually, the team will agree on which version of the 'committed' software will progress to testing, to production, and so on.

The most popular version control software in my experience are Subversion, CVS and Git. These are all standalone applications. Fortunately, each has a plugin that enables you to install it in CFBuilder or Eclipse.

My advise is to first do some reading on each. When we first decided to use version control at our company, a colleague was given some weeks to do nothing else but version control. He researched the options, made suggestions for a choice, and later helped everyone with the installation, documentation, etc.

Using version control will change your ball-game. Henceforth the team will have to agree on the choices it makes. Individuals, however senior or savvy, can no longer just change the code willy-nilly.

Version control implies configuration management, of which it is a part. Parts of the software project that have been baselined for testing or for production, can only be accessed with proper permission. There will have to be a system for monitoring and documenting changes, and those responsible for them. Management has to be involved.

added edit: Up until CF8 we used CFEclipse and CVS. From CF9 onwards we use CF Builder and Subversion.

My use of TortoiseSVN predates Subclipse even existing. I also find the Eclipse Plug-ins to be less functional than the TortoiseSVN client, plus I've found the Eclipse plug-ins to be unreliable at times (although this could be down to user error...): my colleagues have found that sometimes Subclipse struggles with some operations that TortoiseSVN has no problems with. Even the guys using Subclipse still have TortoiseSVN to fall back on.

What do you guys think makes more sense for our 4-people team? Subclipse or Tortoise? Why should we choose one or the other?

This is too subjective to sensibly answer, I think. On our team we use a mix of Subclipse and TortoiseSVN. Some people like the integration with the IDE; personally I separate the notions of writing code and managing code, so don't see much benefit in the integration. I think the sort of difference of opinion on these sort of topics comes from user experience and are just that... opinions.

My use of TortoiseSVN predates Subclipse even existing. I also find the Eclipse Plug-ins to be less functional than the TortoiseSVN client, plus I've found the Eclipse plug-ins to be unreliable at times (although this could be down to user error...): my colleagues have found that sometimes Subclipse struggles with some operations that TortoiseSVN has no problems with. Even the guys using Subclipse still have TortoiseSVN to fall back on.

This is too subjective to sensibly answer, I think. On our team we use a mix of Subclipse and TortoiseSVN. Some people like the integration with the IDE; personally I separate the notions of writing code and managing code, so don't see much benefit in the integration. I think the sort of difference of opinion on these sort of topics comes from user experience and are just that... opinions.

Well, opinions from experienced user are definitely more worth than having no ideas in world full of options ...

Some people like the integration with the IDE; personally I separate the notions of writing code and managing code, so don't see much benefit in the integration. I think the sort of difference of opinion on these sort of topics comes from user experience and are just that... opinions.

Plugins are not as "integrated" with the IDE as you seem to suggest. The part of Eclipse or CF Builder that helps you write the code is quite separate from the part that helps you manage it. That is how plugins came about. They are so separate you're able to plug 'em in and out.

Integration in this case has to do with wiring the two together. This has a great advantage because it reduces the risks from the most error-prone place in all of software development, namely, the point of integration. A thousand things can go wrong, and often do, at integration.

You are correct when you say that issues with plugins may be caused by the user. They quite often are. The advantage of popular plugins, like those of the CVS, Subversion or Git family, is that they are on well-trodden ground. Issues have been reported by an active community of developers, and programmed out.

Didi wrote:

What do you guys think makes more sense for our 4-people team? Subclipse or Tortoise? Why should we choose one or the other?

In my opinion, it is best in these circumstances to have a short-list rather than a single recommendation. Like-minded software competes with each other. Inevitably, each has its pros and cons. In fact, when one software begins to be overtaken by competitors, its developer would go back to the drawing-board, and return later with a better version. It is therefore a poor strategy to home in too early on one choice.

What should -- and will! -- finally decide the choice for you, are your particular circumstances: the skills and ambition of your team, your coding tools and style, your management style, and so on. You have no choice but to look into the alternatives before arriving at your choice. This thread has given you a handsome list to start from: CVS, Subclipse, Subversive, EGit, TortoiseSVN.

No source control recommendation made after about 2001 should include CVS. It's shite, and widely considered thus. No-one with the ability to run Subversion should ever have CVS recommended to them. The ony time one should need to use CVS is if one is doing maintenance work at a shop that already has it 9and for some reason has not ditched it).

You're also mixing source control server-ends and client-ends there. Subclipse, Subversive and TortoiseSVN are just clients for Subversion.

So I'd say Git and Subversion are the source control choices from a server-end perspective; and we've covered the bases with the clients. Although I see there's a Tortoise client for Git now too. Again: I've not used it, so I'm not suggesting it's a recommendation or otherwise. Just a fact.

No source control recommendation made after about 2001 should include CVS. It's shite, and widely considered thus. No-one with the ability to run Subversion should ever have CVS recommended to them.

I think you're being too harsh on CVS. For a start, which version of CVS are you talking about? There are quite a few nowadays, some, like the original itself, still under development or undergoing improvement.

As I said, it is unwise to draw hard and fast conclusions here. Software development is dynamic, and nothing is set in stone. Fortunately.

I can confidently say that, for every "shite, and widely considered thus" remark you find about the original CVS, you will also find a recommendation from a satisfied developer. Yes, even in 2012! The same can be said of the other, more modern, alternatives (after you filter out the 'old is bad because it is old, new is better because it is new' syndrome).

My main suggestion to Didi was, start within, from your own circumstances, and let those factors determine your choice. Don't allow a recommendation, however good or knowledgeable, to impose a choice from the outside in. After all, this is a well-known fact: software choice relies mostly on personal bias and individual circumstances.

Small world! Our development environment is structured more or less the same as yours, Didi, and yours, Adam!

There are 3 stages, counting test and acceptance as one. Each stage has its own database. The main project languages are ColdFusion and Java. Project team sizes vary from 2 to 6.

ColdFusion developers work locally on a development server, each on his own ColdFusion instance(s). We have a protocol on how to commit code, document changes and notify colleagues. A senior developer/architect (sometimes an analyst, but never a developer from the project) deploys the project to the test server and, eventually, to the production server.

My use of TortoiseSVN predates Subclipse even existing. I also find the Eclipse Plug-ins to be less functional than the TortoiseSVN client, plus I've found the Eclipse plug-ins to be unreliable at times (although this could be down to user error...): my colleagues have found that sometimes Subclipse struggles with some operations that TortoiseSVN has no problems with. Even the guys using Subclipse still have TortoiseSVN to fall back on.

I have a question about using Subclipse and Tortoise together...I used to use Eclipse 3.5 and had a Tortoise version earlier than 1.7.0 (but don't remember which version). They both worked together perfectly - the file "decorations" (under SVN control, dirty, etc.) used within Eclipse and Windows Explorer were always in sync and it didn't matter whether you updated or checked out from Explorer (using Tortoise) or from Eclipse (using Subclipse), both environments agreed w/ each other (as far as the file decorations). I then upgraded to Eclipse 3.6.2 and got the latest Subclipse (1.8.0) and it no longer worked well w/ Tortoise. So I updated Tortoise to 1.7.0. It still didn't "work well together" - if I checked out a project from Tortoise, Eclipse didn't recognize the files as being under SVN control and vice versa. I recently tried Eclipse 3.7.2 with Subclipse 1.8.0 and Tortoise 1.7.6. But checking out a new project in Eclipse doesn't show up as under SVN control (with the green checkmark decoration) in Explorer.

What is the "correct" combination of Subclipse and Tortoise so that they "work well together" again? I'd appreciate any help w/ this...our entire team that have updated to the later versions of Eclipse are having the same problems. Thanks in advance!

My use of TortoiseSVN predates Subclipse even existing. I also find the Eclipse Plug-ins to be less functional than the TortoiseSVN client, plus I've found the Eclipse plug-ins to be unreliable at times (although this could be down to user error...): my colleagues have found that sometimes Subclipse struggles with some operations that TortoiseSVN has no problems with. Even the guys using Subclipse still have TortoiseSVN to fall back on.

I have a question about using Subclipse and Tortoise together...

This has been directed at me, but like I mentioned earlier, I only use TortoiseSVN, I don't use the Eclispe plug-ins. So I couldn't sensibly comment.

Hopefully someone else paying attention to this thread might be in this boat, and have something to add..?

I have a question about using Subclipse and Tortoise together...I used to use Eclipse 3.5 and had a Tortoise version earlier than 1.7.0 (but don't remember which version). They both worked together perfectly - the file "decorations" (under SVN control, dirty, etc.) used within Eclipse and Windows Explorer were always in sync and it didn't matter whether you updated or checked out from Explorer (using Tortoise) or from Eclipse (using Subclipse), both environments agreed w/ each other (as far as the file decorations). I then upgraded to Eclipse 3.6.2 and got the latest Subclipse (1.8.0) and it no longer worked well w/ Tortoise. So I updated Tortoise to 1.7.0. It still didn't "work well together" - if I checked out a project from Tortoise, Eclipse didn't recognize the files as being under SVN control and vice versa. I recently tried Eclipse 3.7.2 with Subclipse 1.8.0 and Tortoise 1.7.6. But checking out a new project in Eclipse doesn't show up as under SVN control (with the green checkmark decoration) in Explorer.

You have actually replicated our my experience with working with the two together. To cut a long story short, no one in the team currently uses both Subclipse and TortoiseSVN any longer. The main cause was that the underlying Subversion version diverged. One consequence is that those in the team who stuck with Subclipse have lagged several versions behind those who went with TortoiseSVN.

We used them together on Eclipse 3.5(Galileo) and Eclipse 3.6(Helios). On Galileo, you had a choice between Subclipse 1.4.x (based on Subversion 1.5) and Subclipse 1.6.x (based on Subversion 1.6). On Helios we had just Subclipse 1.6.x(Subversion 1.6). You could also use, respectively, TortoiseSVN 1.5 or 1.6. The version numbers of Subclipse, Subversion and TortoiseSVN matched nicely.

Then there was a spurt in the development of the Subversion server software. 1.6.x quickly became 1.7.0, 1.7.1, and so on. Subclipse and TortoiseSVN kept up with the changes, but did so differently, with Subclipse lagging behind. For some odd reason, TortoiseSVN 1.7.4 got linked against Subversion 1.7.2, and TortoiseSVN 1.7.6 against Subversion 1.7.4, breaking the pattern. Subclipse 1.4.x, 1.6.x and 1.8.x require, respectively, matching client API versions 1.5.x, 1.6.x and 1.7.x. Notice, for example, that it wasn't until Subclipse 1.8.x that Subclipse raised its game to Subversion 1.7.0. There, to my mind, lay the reason for the parting of ways between Subclipse and TortoiseSVN. It simply became difficult to keep up with the version changes.

We opted for a move to Subversion 1.7.0, as it is the first, major, all-encompassing release of the server since it officially became an Apache project 2 years ago. Now, lazy b'tards like me, will continue with what they've always been used to. In my case, Subclipse 1.8.x on Eclipse 3.7.2(Indigo) and Subversion 1.7.0. Though still with some teething problems.

If, in spite of the version perversion, you still wish to combine TortoiseSVN with Subclipse, then match them according to the Subversion version. For example, Subversion 1.7.0 implies matching Subclipse 1.8.x with TortoiseSVN 1.7.0.

OK - I finally got a chance to try this out. I'm not sure where I got that I was using Subclipse 1.8.0 because I had 1.6.5. (Can't remember if I reverted back to 1.6.5 after commenting in this thread or not... ) Anyway, I downloaded Subclipse 1.8.9 and it had Subversion JavaHL and SVNKit stuff at version 1.7.4, so that seemed like it would match my TortoiseSVN 1.7.6 (which showed it used Subversion 1.7.4). I would've thought these would all work together nicely. But when I checked out a program from subversion using Eclipse (Subclipse), it now looks fine in Windows Explorer (had file decorations), but in Eclipse, it treated everything as unversioned (blue question marks). Sigh.

Do you think it's worth reverting my TortoiseSVN from 1.7.6. to 1.7.0 and trying it all again?