Skip navigation
Didi
Currently Being Moderated

Win2008R2 / CF9 plus 3*Win7-64 /CFB2

Feb 8, 2012 6:49 AM

Hi there

 

we have just upgraded to Win2008R2 / CF9 and 3 clients with Win7-64 /CFB2.

Now we think about the ideal configuration to work in our group.

Somehow we are struggling on different points when setting up the whole. There are some tricky steps ..

Well, this just as a general comment.

 

Some questions raise:

 

When I setup a project to a folder in my webroot, productive templates and CFB2 metadata are stored at the same place. I would like to separate those:

Productive templates in the webroot, CFB2-specific files in a folder outside the reach of Apache.

Somebody having a good idea how to do that?

 

We are three developers. Is there somewhere a good practice manual how to use CFB2 in a collaborative environment?

 

Thanx for help

 

-Didi

 
Replies
  • Currently Being Moderated
    Feb 19, 2012 11:49 AM   in reply to Didi

    No you're not.

     

    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.

     

    It sux a bit in this regard.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 8, 2012 1:01 PM   in reply to Didi

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 2:03 AM   in reply to Didi

    Adam:

    You use tortoise instead of the Subclipse?

    Is this because of the installation problems?

     

     

    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.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 5:09 AM   in reply to Adam Cameron.

    Adam Cameron. wrote:

     

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 5:21 AM   in reply to BKBK

    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.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 6:05 AM   in reply to Didi

    Well, since at our place there is already a Subversion server doing its job, we won't invent the wheel twice ..

     

    So we 'only' have to find out about the client.

     

     

    Well: I recommend you try both and decide which you prefer to work with.  Only you (and your team members) can decide that.

     

    You've got about as much subjective info as can sensibly be used already on this thread.

     

    If you want more opinions, perhaps google "subclipse subversive tortoisesvn opiniona" and see what other people have said.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 7:27 AM   in reply to Adam Cameron.

    Adam Cameron. wrote:

     

    CVS, Subclipse, Subversive, EGit, TortoiseSVN.

     

    You're also mixing source control server-ends and client-ends there. 

    No, I am not. My intention was to mention the clients/plugins. The underlying server follows.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 11:04 PM   in reply to Adam Cameron.

    Adam Cameron. wrote:

     

    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. 

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 11:37 PM   in reply to Didi

    Didi wrote:

     

    Well, since at our place there is already a Subversion server doing its job, we won't invent the wheel twice ..

    In this case, your place is the best place to start.

     

    So we 'only' have to find out about the client.

    Subclipse plugin

    Subversive plugin

    SmartSVN (standalone; integrates into Windows shell)

    TortoiseSVN (not standalone; integrates into Windows shell)

    (Added remark: I have restricted myself just to the clients I've worked with)

     

    Get fellow developers involved (for example, by actually playing around with the software). Keep management in the know.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 10, 2012 4:16 AM   in reply to Didi

     

    Could you please shortly describe in one or two sentences the difference between Subclipse and Subversive?

     

     

    I can do better than that:

    http://lmgtfy.com/?q=subclipse+vs+subversive

     

    It's not the first time someone has wondered the same.

     

     

    Also, one more question now came up concerning the development environment.

     

    So far, some of us (meanwhile 4 on the same project) used a personal CF server for development and staged later on the code to a common server.

    On the other hand, we could use one single development server.

     

    How are you guys working in the team?

     

     

    We've always developed locally and deploy to a separate QA server once the release is ready.  We connect to a shared DB server for one reason or another.

     

    This is pretty much the way I've worked at any shop I've been in for the last ten years.

     

    --
    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 10, 2012 5:48 AM   in reply to Adam Cameron.

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2012 9:25 AM   in reply to Adam Cameron.

    Adam Cameron. wrote:

     


    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!

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 22, 2012 3:59 AM   in reply to Bob U

    Bob U wrote:

     

    Adam Cameron. wrote:

     


    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..?

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 25, 2012 3:07 PM   in reply to BKBK

    BKBK wrote:


    Subclipse plugin

    Subversive plugin

    SmartSVN (standalone; integrates into Windows shell)

    TortoiseSVN (not standalone; integrates into Windows shell)

    (Added remark: I have restricted myself just to the clients I've worked with)

     

    Hey BKBK, maybe you can answer my question from #17 about using Subclipse and Tortoise together...(hopefully).  Thanks!

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 6:00 AM   in reply to Bob U

    Bob U wrote:

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 26, 2012 7:17 AM   in reply to BKBK

    Thanks, BKBK!  That's very informative and exactly what I was looking for.  Thanks, again, for taking the time to help!

     
    |
    Mark as:
  • Currently Being Moderated
    May 14, 2012 3:13 PM   in reply to BKBK

    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?

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points