Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Number of attachments :
Description
Scenario is as follows:
1. I created a user branch and did some work, including adding a new file.
2. I svn added the new file and committed everything (including the new file).
3. I switched to trunk and created a new user branch while waiting for a code read on the work in the first user branch.
4. I manually copied over the changes from the first user branch into the second user branch because I needed to build on it. I manually created the new file in the second user branch.
5. I was ready to go back to the first user branch to promote my changes, so I stashed my changes in the second user branch by committing it. However, I forgot to svn add the new file and check it in.
6. Since I had never svn added the new file, svn didn't know about it, so I was able to switch back to the first branch by doing a sav sb first_user_branch.
However, savana blew up at the end of its process of switching branches because I had a local file that conflicted with a svn added file in the first user branch. At this point, I could not perform any savana commands because savana had done the svn switch but had not updated the savana metadata. So it kept complaining that the local branch did not match the repo branch.
IMPORTANT NOTE: All of this was done from a folder WITHIN the folder where the .savana file is located. Our folder structure for this particular project is jank: the root of the project (where the .savana file lives) contains one and only one folder, which contains all the source. So I am always doing work from within that inner folder. I have done all my savana commands from within that folder (including switching branches and so forth) without any problems in the past. I am just mentioning it because Bryon was surprised that this works; it may in some way have contributed to the problem above.