Kuno Baeriswyl wrote:
> the following maven issue (http://jira.codehaus.org/browse/SCM-406) seems to
> be svn issue that was introduced in svn 1.5.1. I'm highly interested that
> this issue will be fixed and want to make sure that your team is involved.
> It looks like nobody took care of this problem so far.
Kuno,
Can you give us a link to where somebody has clearly described the
problem with Subversion? I looked through that Maven issue report and it
isn't clear. How can we reproduce the problem? What is the Subversion
command issued and the exact result, compared with the expected result?
What I understood is that the problem is in making a tag from a
mixed-revision working copy by using "svn copy" from WC to repository.
1.4.x and 1.5.0 were OK and the problem occurs with svn 1.5.1 through
1.5.4. It wasn't clear to me whether the "--non-interactive" switch is
part of the problem. It wasn't clear what the exact error messages were.
Is it <http://subversion.tigris.org/issues/show_bug.cgi?id=3059>, "Mac
OS X 10.5 (Leopard) breaks --non-interactive"?
The following comments from that Maven issue report seem the most
relevant:
[[[
> Michael Johns added a comment - 11/Sep/08 12:53 PM I have a little
> color I can add to this discussion. We too use Maven, but I'm 99% sure
> this has nothing to do with it. Here's what I've done:
> 1. Ran a release in Maven; failed with the error everyone else is
> seeing (svn: File '...' already exists) 2. In a command prompt
> on our build box, changed to the project's working directory
> that was created by the Maven build. From there, ran a "svn
> --non-interactive copy -m <message> . <test destination>"
> manually (same command that Maven runs, save for an explicit
> message rather than --file). Got the same error.
> 2. Queried the working copy to see if any files were changed. No
> files were changed, but about 10 new files were present
> (relics from the aborted build).
> 3. Deleted the new files and ran the command again. Failed again
> with same error.
> 4. Ran an update on my working copy. No changes happened (no new
> files, deleted files, or changed files), but something
> happened because...
> 5. Ran the command again, and it worked.
> Some things to note:
> * We have a multi-module project.
> * We're on Windows Server 2003.
> * I installed SVN using various methods (msi, unzip), and they
> all fail. We have 1.5.2 with the Apache 2.0 bindings.
> * This problem doesn't happen with SVN 1.5.0, but it does happen
> with 1.5.1.
> To me, this most definitely appears to be a SVN bug. I've also posted
> this to the subversion users mailing list since it's really more
> relevant to them. But I figured I'd cross-post it here to help
> exonerate Maven as the culprit.
]]]
I found Michael Johns' message to the Subversion users mailing list at
<http://svn.haxx.se/users/archive-2008-09/0395.shtml>.
[[[
> Alison Winters added a comment - 28/Sep/08 11:10 PM This does appear
> to be an SVN "bug" in the sense that it doesn't let you tag from a
> non-head revision, even if all the files in and below the current
> directory are in fact at the latest revision for that directory on the
> repository. I think perhaps Maven should hide this by explicitly
> running an svn up prior to the svn copy - it makes sense anyways
> because presumably you do always want to release from the head version
> of what's in the repository.
]]]
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=982114
Received on 2008-12-10 11:55:10 CET