-
Suggestion
-
Resolution: Unresolved
Crucible currently (4.8) cannot anchor a patch for a file with revision "nonexistent" which is a new file which has not been committed yet. It can, however anchor patches when the revision number is revision 0.
Since there seems to have been a change in the way SVN (or Tortoise SVN) handles patches in newer SVN versions 1.9+ which are supported in modern versions of Crucible, we should be able to handle this case. (tortoisesvn - Unable to parse diff revision header 'non existent' in tortoise svn? - Stack Overflow
More details
In SVN 1.7 (and reportedly 1.8) such new files were delineated in the patch as below, being a diff with respect to revision 0, essentially:
Index: path/to/file.ts
===================================================================
— path/to/file.ts (revision 0)
+++ path/to/file.ts (working copy)
While on newer SVN versions the generated patch instead marks the file as nonexistent in the working copy, and Crucible is unable to draw an equivalence between this new notation and the previous revision 0 reference
Index: path/to/file.ts
===================================================================
— path/to/file.ts (nonexistent)
+++ path/to/file.ts (working copy)
Clarifications
Note, that it should only be able to anchor new files when the patch also contains diffs from existing files. A patch containing only new files will not be anchored.
When trying to anchor a file, Crucible will search for matches in the files in its database. Crucible will analyze all the paths in the patch, find the branches containing all those paths, then anchor the patch to the trunk or the branch with the most recent commit activity - so the path needs to have already been committed.
Workaround
Manually replace nonexistent with revision 0 before uploading the patch, for example
sed s/nonexistent/revision 0/
Hi everyone,
We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Not Being Considered.
Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Fisheye&Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Implementation of New Features Policy for more details.
We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.
Kind regards
Marek Parfianowicz
Development Team Lead