Branch creation without tags and trunk folders

[notec]

We had our dev create a new branch folder and work from there. When it came time to create a release candidate, they used svn copy instead of svn merge because the tags and trunk folders did not exist yet.

When I run:

svn mergeinfo --show-revs=eligible  .../branches/XXXX /trunk

r98360
r98361
r98373
r98447
r100277
r100280
r100281
r100282
r100287
r101154
r101207
r101511
r101512
r101515
r101517
r102879
r102897
r102902
r103226
r103235
r103243

it shows all commits still have not been merged (I expect nothing to be returned when running this command).

Whats the best way to correct the commit history now the the trunk and tags folders are created and show that the code from branch is now merged to trunk when I run the above command?

[andyl]

If there's no trunk or tags, where did branches get created?

You're seeing all the commits because no merge has been performed yet - therefore ALL commits are eligible to be merged without risk of re-merging.

You can't change the history (if you could, all kinds of other things would break), but you should still be able to do the following:

1) Roll back the "copy" so that what's now trunk looks the way it did before that happened.
2) Merge all your changes over to trunk from the branch.

[notec]

If there's no trunk or tags, where did branches get created?

It was brand new code. This is first time creation. There was no trunk to merge in to create the branch from....

[andyl]

It was brand new code. This is first time creation. There was no trunk to merge in to create the branch from....

I'm not following what you're describing.

We had our dev create a new branch folder and work from there.

This implies that there was something in your repository when you created the branch. Where did this come from? And where is it in relation to your branch?

When it came time to create a release candidate, they used svn copy instead of svn merge because the tags and trunk folders did not exist yet

This is normal - you make a copy (branch) of your code for the release candidate. When the RC is complete (although hopefully prior to that as well, so that the original and RC don't deviate too much), you merge your changes back to the original & close out the RC branch.

If work is continuing on the next release, that shouldn't be merged into your RC branch in a sane development/release methodology. Fixes needed during the RC process should, however, be merged back to the trunk (or whatever you're calling it) so that old bugs don't re-appear in the next release.

[notec]

I'm not following what you're describing.

This implies that there was something in your repository when you created the branch. Where did this come from? And where is it in relation to your branch?

Just found out there wasn't. So we really didn't need to branch here.

Thanks for your reply it helped me articulate what was needed to bring the folders back inline (if that makes sense).

Which I had them do this:

1. Run svn export to put the working copy of your folder off to the side without .svn files (unattached from SVN)
2. Delete the entire structure of the project in SVN: delete branches; tags and trunk
3. Recreate structure: branches; tags and trunk
4. Commit exported working copy of the folder to the trunk
5. Create Branch from trunk (using TortoiseSVN)
6. Merge branch to trunk and release.