Community
Participate
Working Groups
Build Identifier: Headless Buckminster 3.7, with Indigo SR-2 tooling. Latest versions available at 2012-02-28 I moved a project (OSGi bundle) in a branch, and merged the branch to trunk, in my SVN repository. I then asked Buckminster to import that project from trunk, from HEAD revision (=YYYY). It found the project, and the last change revision XXXX was determined. This is probably done using 'svn info url@YYYY'. Buckminster then tried to list the files in that project, using 'svn ls -r XXXX url@XXXX'. This is due to a change for bug 350011 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=350011). Before that change, 'svn ls -r XXXX url' was used. However, since my project did not exist at the current location in revision XXXX, Buckminster fails due to SVN reporting a URL_NON_EXISTENT error. I think the solution is to use 'svn ls -r XXXX url@YYYY' instead. Note that as a temporary workaround, I simply commit dummy changes in the project, to make sure that XXXX and YYYY are the same, namely HEAD. That is, the project is then changed AFTER it was moved, thus avoiding the whole issue. Reproducible: Always Steps to Reproduce: 1. See test-files.zip: Extract the files into a fresh empty directory. 2. Run ./svn-test in that directory. It does the following: 3. Create a repository and check it out. 4. Create trunk/branch structure, and add an OSGi bundle/project to trunk. 5. Create a branch and check it out. 6. Move the project in the branch. 7. Merge the branch into trunk. 8. Update trunk. 9. Remove the branch. 10. List the project in the repository, in the old and new locations, using different peg/operative revision combinations. 11. Run ./buck-test in the same directory. It does the following: 12. Use Buckminster to import the project from the SVN repository trunk, in the old location, in a revision where it existed at the old location. 13. Use Buckminster to import the project from the SVN repository trunk, in the new location, in the HEAD revision where it exists at the new location. See how 12 succeeds (due to changes in bug 350011). Also see how 13 fails (that's what this bug is about). The proposed changes should make both 12 and 13 succeed.
Created attachment 211780 [details] Test files, as mentioned in bug description.
I don't want to revert 350011 and cause a regression for the problem that it fixed so I'm not sure what you're suggesting. What is needed in order to fix both your problem and the problem that was fixed in bug 350011?
(1) Before 350011: svn ls -r XXXX url (2) After 350011: svn ls -r XXXX url@XXXX (3) Proposal: svn ls -r XXXX url@YYYY (1) didn't work for 350011, as the project didn't exist in head, and @HEAD was implicitly used. (2) doesn't work for my case, as the project didn't exist in revision XXXX, and @XXXX is used. (3) should work for both cases
(3) Proposal: svn ls -r XXXX url@YYYY Just to be clear: YYYY is the revision we requested Buckminster to build (using cquery advisory node revision). Then Buckminster does: 'svn info url@YYYY' to get the last change revision (XXXX). Then, to list the contents of the project folder (and also to check it out I think), Buckminster should use: 'svn ls -r XXXX url@YYYY' instead of 'svn ls -r XXXX url@XXXX'
Got it! Thanks for explaining.
