I am working with Accurev and recently I was forced to perform a revert on a recent promote. I followed the general guidelines, accessed the stream's history and performed a revert action on a selected transaction. That particular transaction involved already existent files but also new ones.
Now here comes the main problem: after the revert the existent files were returned to their previous version but the files that were at their first version appeared in the root of the stream regardless of the path where they were initially placed and were in the state Defunct. Of course this mainly visually disturbing but I am also wondering what will happen later on when someone will try to readd those same files to the stream.
Will there be a conflict, will they be repositioned where they were initially added? At this point I am thinking about reverting the revert action but it already seems really overcomplicated and it look like it would only generate more problems.
Lets say you have a stream hierarchy of: Stream1 - Stream2 - Workspace1
In this hierarchy you have a file called foo.c.
In Stream2, this file has a defunct status.
If you add foo.c to source control in a Workspace1 and promote, the defunct version in Stream2 is now stranded and the newly added appears with a member status. The stranded file will appear when you search for stranded elements.
If you try and promote the newly added foo.c, it will fail due to being an evil twin as the original foo.c still exists in Stream1.
To clear this, you can promote the stranded foo.c from Stream2 and then promote the newly added foo.c.