2 Replies Latest reply: Oct 6, 2006 9:54 AM by 523966 RSS

    jDev SVN Problem

    523966
      I made a minor change to a css file in a text editor and committed it back to the repository using TortiseSVN. Next time I opened the project in JDev it reported that all of the files in the same directory as the modified css file were candidates to be added to the repository. I checked the repository and the files are still there.

      I experimented and found that any time TortiseSVN was used to commit a file back to the repository JDev promptly "forgets" that all of the files in the same directory are part of Subversion.

      Does the Subversion plug-in in JDeveloper not play well with this version 1.4.0 of TortiseSVN? Anyone else seen this?
        • 1. Re: jDev SVN Problem
          John Stegeman
          Hi Chris,

          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,

          John
          • 2. Re: jDev SVN Problem
            523966
            As far as I know, the JDev SVN plugin was built to work with version 1.3.x
            Bingo. 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.

            Chris