This content has been marked as final. Show 2 replies
A couple of comments:
As far as I know, the JDev SVN plugin was built to work with version 1.3.x (not sure of the value for x) of the SVN client. Do you see the same problem with the older version?
Having said that, I am using SVN 1.4 - I have the JDev SVN plugin installed; however, I perform all of my repository actions using the command-line client (svn commit, svn update, etc). JDeveloper does seem to properly perform some actions for me, such as doing the proper actions when deleting a view object or renaming classes.
In my experience, SVN works really well in this environment (we are using ADF BC/ADF Faces), much better than CVS. In fact, we originally gave up on CVS because we had some inconsistent commits (some of our developers were on a really slow wan link, and their commits would time out halfway through), leading us to completely broken ADF BC code. Using SVN, this cannot, by design, happen.
One "beef" that I do have, is that if I have the "pending changes" window open, JDeveloper/SVN take a really long time to analyze whether I have any pending changes. Simply doing "svn status" or even "svn status -u" from the command line takes at most a few seconds, whereas JDeveloper can take several minutes to come up with the same answer.
On a practical note, the one area where we seem to have the most conflict, or at least potential for conflict, is on the application module. Especially at the early stages of the development cycle, multiple developers are all trying to get View Objects into the Application Modules, and SVN usually cannot merge those types of changes very easilly. Once we have our business service layer fairly stable, these types of problems go away. We have implemented a process where developers always run svn update on the AM, make their change, and commit as quickly as possible to avoid this scenario.
The other point is that we seem to always have changes to commit in the xcfg files, even though we use the same connection names in JDev. I have simply taken to having a batch file that "svn revert"'s the .xcfg files before I commit.
Sorry for "hijacking" your thread; hope it's helpful,
As far as I know, the JDev SVN plugin was built to work with version 1.3.xBingo. Got it in one. Version 1.4 uses a different format that isn't backwards compatible. I downgraded to the last 1.3.x release and everything worked fine. I just had to check out a fresh copy from the repository. I'd been using 1.3.x on my old machine and decided to upgrade when setting up my new one.
I agree with your comments about the workflow of using the SVN plugin - especially the speed at which the pending changes window operates. The xcfg comment was spot on as well.
Thanks for the help.