1
The scenario is the following:
- trunk is branched to A
- trunk is added directly folder1 with files file1 and file2
- A reintegrates trunk
The result is that when committing the merged working directory into A, its status is that:
folder1 added folder1/file1 not to be seen, marked as up to date with repository folder1/file2 not to be seen, marked as up to date with repository
So the commit ends up adding folder1 to the branch, but it doesn't add the files. So they remain in the working directory as under version control, but they're not...
My workaround is, after this commit:
- move out this "added" folders
- commit the delete
- move back the folders
- commit
As this doesn't quite often it's doable, but it is far from a decent solution, so I think I'm definitely missing something...
I've tried all sorts of cleanup and nothing marks those new files as "added" (to be committed)...
What specific command (actual svn command, as typed) did you use to "reintegrates trunk" on branch A? A "reintegrate merge" is the WRONG merge to do here, if that's what you did. – Ben – 2013-11-06T06:36:41.263
I'm thinking it was not the proper merge type indeed, specially as it says in the usage description "reintegrate back to trunk". But I am using TortoiseSVN and there are 2 other options (merge range of revision and merge 2 diff trees) and both required specifying a range of revisions when I basically want "since branching revision up to trunk HEAD".. Re-integrate seemed to do that. Should I use range of revisions and manually check the "branching revision number"? thanks – Filipe Pina – 2013-11-07T18:27:58.027