This content has been marked as final. Show 36 replies
update working copy will never wipe out your local changes. If you want to do that, you should use revert.
subversion update will atempt to get changes from the server and apply them to your working copy (or merge them into your working copy if you have changed the working copy too). If it cannot merge, then you will get a conflict.
what I want is to discard my changes in my local working copy. I don't want to merge with the revisions in svn server. If Update working copy does not wipe out the changes, what should I use?
So we have to manually revert the changes locally and manually delete the new files in the application navigator window?
Also, there are some files that don't show up in the navigator window like the files under the .designer directory, we have to go out to windows explorer and delete it. That's too much of work that a user has to keep track of.
Shouldn't a version control system do this task instead of the user?
Subversion has a "revert" command, which is what you use to wipe out local changes. You can do this in JDeveloper also. The versioning menus expose the "revert" command.
revert: wipe out local changes to your local copy
update: copy or merge changes from the server to your working copy (may generate a conflict)
commit: post the changes in your working copy to the server (will fail if there are other changes on the server which you have not applied, which is why it's good practice to do an update before you do a commit).
Dunno whether you've read [url http://www.oracle.com/technology/pub/articles/adf-development-essentials/index.html]these; they may help you.
yes, I'm using revert for existing files now. How about new files? We have to manually delete them?
Yes. This isn't anything to do with JDeveloper, but with Subversion - if you create a file and don't want it anymore (before you add to SVN), just delete it as normal. Revert will not wipe it out.
If you have lots and lots and lots of changed/new stuff and you just want your working copy to reflect the repository, just delete your whole working copy (from the file system) and check out a fresh copy. Either way works.
Thanks John. I got this error and I think it's a bug with JDeveloper 220.127.116.11 since it does not appear in 18.104.22.168. When I check out my application from SVN into a new working copy directory, I got the below error
SOA MDS Store Validation
One or more metadata store location(s) configured in file:/C:/workspace/.adf/META-INF/adf-config.xml are invalid
SOA project(s) will not compile! Please edit this file and fix metadata-store location(s).
My SOA application has 1 SOA project with an empty composite. It's very simple.
Can you let me know if this is a bug in 22.214.171.124 please?
I think you very likely had a file-based MDS store in your application (check the referenced adf-config.xml file) and you forgot to import that file-based MDS store into SVN; now when you check out a fresh copy, the file is not there, and therefore JDeveloper complains. If you have the file sitting around from an old working copy, just put it into your new working copy in the proper location, add to SVN, and commit.
If you initially imported the project into SVN via JDeveloper, then there perhaps may be a bug if JDeveloper didn't import the now-missing file, but whether it's a bug or not probably depends upon how you did the import - Support would be the best place to diagnose that and then to file a bug if one does in fact exist.
Here are the steps I did, very simple
1) Create a new SOA application and project in JDeveloper
2) Commit into SVN
3) Check out the new application into a brand new directory
Below is the content of the adf-config file after I'm done with step 1 above. This is a brand new SOA application so I do not have any special configurations. I just checked everything into SVN at the application level. I created a new folder in the trunk folder. I did not create any new filters when I first imported it into SVN. I use the existing list that came from JDeveloper.
<?xml version="1.0" encoding="windows-1252" ?>
<adf-property name="adfAppUID" value="Application2-2754"/>
<namespace metadata-store-usage="mstore-usage_1" path="/soa/shared"/>
<property value="seed" name="partition-name"/>
I haven't had the opportunity to do much with the SOA suite in 11g yet, so I cannot comment one way or another from my own experience. I'd recommend you file a support request (if you have support) or, barring that, start a new thread to address that issue. You may also want to post it to the SOA Suite forum as well. I'll mention this thread to the Oracle PM who does the SVN stuff, but no promises there ;)
Thanks John. You are very helpful :)
I am the PM that John refers too! Are you also the user who posted a similar question to my blog? I need to look into your scenario and will get back to you on this forum next week. But I can confirm John's comments - Update will never overwrite local changes. But, if your changes and the changes on the server do not conflict, it will add both 'changes' in your local copy.
Yes I'm the same person. Sorry I posted it in 2 places because we need to use SVN and JDeveloper ASAP so we are testing JDeveloper to see how it integrates with SVN because it had a lot of issues integrating with SVN with the previous version of JDeveloper. I'll encounter another error as below
an unexpected severe error has occurred in JDeveloper
The program may be unstable, which could result in data loss. Decide how you want to proceed and click OK.
1) Save all files and exit
2) Exit without saving
This happen when I refreshed the pending changes view after taking changes from others, when I update the Incoming changes from 1 working space to another.
I've seen it happened before at other places also and I'm trying to reproduce it now. I'll post what my findings are in this forum when I have them soon. For now, I just click on continue so I can continue working.
If you can give me a reproducible test case that will help me enormously. Ideally, an application zip that I can work with.
No problem posting in two places - but this forum is the best way to get answers, as it may be that another user has encountered a similar scenario and can offer help in addition to the Oracle PMs.
I'm compiling a set of test use cases and will send them to you soon. Please let me know when you have answer regarding the SOA MDS Store Validation error.