Recently I've been speaking with a number of JDeveloper/SVN users concerning the level at which they version their code. While I still maintain that the best way is to create a working copy at the Application level there are times and development process requirements when this isn't practical or possible.
Take this example: A team development with one Application split into many Projects. The Application is under source control using SVN. Their development process mandates commits are done per Project. There are a number of ways to achieve this, here are my suggestions for a team member to work on one or more projects and be selective about what is committed:
Alternate Take 1: Check-out each project as a separate working copy
- Create a new empty Application with no projects
- Use the SVN Navigator to select the root node of one of your projects in the repository
- Check this project out of the repository
- For the check-out destination, select the root folder of your newly created application
- You will get a warning on the Confirm Check Out dialog that you have selected a directory that is not empty - this is OK
- Continue to check out projects under your application root folder
- Now you can use JDeveloper's Commit Working Copy command on any node in a specific project and that project's changes will be committed.
Using JDeveloper 11g you can filter the Pending Changes window by application or project. In the screen shot below I've filtered my outgoing changes to myProject1. I can select one or more of these files and with the context menu Commit Working Copy or Commit. I'd choose to select all the files and Commit if I had checked out my Application as the working copy. I'd choose Commit Working Copy if I had used Alternate Take1 to check out each project as a working copy. Unfortunately JDEV 10g doesn't have this filtering ability so this is an 11g only Alternate Take
I'm sure there are other Alternate Takes to both the level at which you version your code and how you manage checkin/out. I'd love to hear the good practices and the pitfalls.
2 comments:
Hi Susan,
I strongly agree with your original take - versioning at the application level - the reason that versioning at the project level would not work for me is that there are dependencies among the projects (at least in the projects I work on) that would break the application if I only committed a project at a time. The obvious example - ADF Business Components in one project and the UI (ADF Faces with binding) in another. If I were to make a change such as adding an attribute to a view object and then adding it to a JSPX page - to me, that is a single development activity, and should be committed as a single change; in such a simple case, our bug tracking/enhancement tracking system would likely have a single ticket for such a request. Single change = single commit. It is obvious that if I committed one project at a time in that case, I've just broken the build.
However, I do understand that not everyone uses ADF BC/ADF Faces broken apart into projects this way, but I do - thus, versioning at the application level is the proper way for me.
Best regards
Hi John,
Application level versioning is my preference too. But I do have customers who (even using BC) prefer the project approach. For instance, I have one customer who wants to provide EO/VO centrally in a project that teams develop UI on top of in their own applications. But rather than using the library approach wants developers to be able to checkout and see the BC project. I'm working through this scenario at the moment.
Post a Comment