In AccuRev, when I look at the history for a file (in "history mode"), I see a list of the actions that were taken on the file. Each action has a number (#) and a version.
When I click on one of these actions, another list appears that shows each of the files that was involved in the action (including the one whose history I'm investigating). Each entry in this lower panel has a "virtual version" and a "real version".
The "version" in the top panel appears to be the same as the "virtual version" of my file in the lower panel.
What is the difference between the #, the virtual version, and the real version? Why do virtual and real versions have two numbers separated by a slash?
I found the AccuRev documentation to be confusing. Here is what I've come to understand:
# is the transaction number. Every action in an AccuRev depot is assigned a unique (auto-incrementing) transaction number. When multiple files are affected in one action, they share the transaction number.
"Virtual version" is the stream name (or number), followed by a slash, followed by the count of which version it is on that stream. So, the first version of helloworld.c on the IntegrationStream is IntegrationStream/1, or perhaps a number like 123/1. If AccuRev shows you a number you can look up the corresponding stream name. If multiple changes have been kept on the file in another stream and the file with multiple changes is finally promoted to this stream (IntegrationStream), this increments the number only by one. So the next version visible on this stream would be IntegrationStream/2 (or 123/2).
The "real version" refers to the first time that revision of the file was seen in the depot. This would be when the original keep operation was performed in someone's workspace. So if the version of the file seen in IntegrationStream/2 is the result of a keep in Proj_jsmith/7 which was promoted up to IntegrationStream, then the real version shows up as Proj_jsmith/7.
The ancestor, merge and patch version, if applicable, can be best understood by switching to "version browser mode" where the ancestor, merge, and patch lines are shown. Those columns in the lower panel grid refer to the versions that are associated to the given version of a file by preceding it as an ancestor or by being the source of a merge or patch.
# is the transaction number, it is incremented for each depot changing operation and is incrementing continuously.
The difference between Real Version and Virtual Version is described in AccuRev help (%PROGRAMFILES%/AccuRev/doc/WebHelp/InDepth_Real_and_Virtual_Versions.htm)
Related
To automate Perforce staging, I face a dilemma that add and edit are two different ops and they work on files of different SCM status, i.e., "already under SCM or not".
This is different from git where staging is uniformly add.
I'd like to have something like pseudo-code:
filepath = '/path/to/myfile.ext'
if p4.is_under_scm(filepath):
p4.edit(filepath)
else:
p4.add(filepath)
or better yet, simply hide the detail with:
p4.staging(filepath)
How should I achieve this with calling p4 command-line program?. I'm not using any programming-language bindings right now.
You might want to use the p4 reconcile command, which automatically opens workspace files for an action that matches their current state relative to the depot.
Keep in mind if you go this route that reconcile operates only on unopened files that are different from the depot version, so it's meant to be used after making local modifications (this is different from the standard workflow where you open a file with p4 edit prior to editing it -- the idea is that you use reconcile to fix things after the fact if you've had to work disconnected or something like that). In addition, if you change your mind about what you're doing with the file (e.g. you delete the local copy after it's been opened for edit but before you submit), you may need to revert -k it and re-reconcile to ensure that it's open for the correct action.
For something that matches the pseudocode in your question, you probably want the p4 have command, which tells you if a local file corresponds to a depot revision (and if so which one). p4 edit only works on a file that you have, whereas p4 add would be for a file in your workspace that does not correspond to an existing depot file. (A very subtle point here -- it's possible for the file to map to a depot file despite not having been synced from the depot! If that's the case you'll hit a conflict when you go to submit your add.)
Is it possible to promote a file without specifying an issue number?
Related to that question, I see some files which have histories for which the column "Issues" is blank. How does that happen?
Promoting against and issue is an option, rather than a requirement. An AccuRev depot does not have an AccuWork schema until an administrator creates one. Even then, this does not automatically require promoting to an issue. Within the Accuwork schema, this feature can be enabled using the Change Packages tab.
To your second point "... some files which have histories for which the column "Issues" is blank. How does that happen?"
If you've changed over from non-Issue based development to Issue based development and have not associated the files, those with active or (member) status, with Issues, that column will be blank.
More likely some one promoted foo.c to Issue 15. Then opened up Issue 15 and removed foo.c from the Issue. In this case the column will be blank too.
The solution is to find these files, look for the "Unaffiliated Changes", select them, and choose "Send To Issue" then provide the correct Issue number.
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.
We have a need to refactor a code base. The thing is that this will be done by one person and it would be desirable to avoid having the rest of the development team sitting idle while this job takes place.
We therefore tried the following scenario to see if it is possible to work in parallel.
Created file test.txt in directory first in developer A's workspace.
Promoted this file.
Updated developer B's workspace, thereby getting file test.txt
In A's workspace moved file test.txt to directory second.
Promoted this move.
In B's workspace edited file test.txt while it still resides in directory first (no update is made thereby emulating that work is done while refactoring is taking place).
Tried to promote and got a message saying that file test.txt had been modified (correct, file has been moved).
Tried to merge but got an error message saying that AccuRev can't merge since the file is missing in directory second (where it has been moved).
Tried to update B's workspace but that is not allowed since there is a modified file that needs to be merged first.
We are now stuck in a catch 22 situation.
We did try to place a fake file in directory second but that is not being recognized since this file does not belong to the workspace.
Has anyone out there tried something like this and gotten it to work?
It is of course possible to copy files but if there is a better way we would be grateful to hear about this. Or if this is a known bug or limitation in the tool.
We will contact also contact AccuRev support but I thought that I might be able to get some useful tips from the community.
Currently we are using AccuRev client 5.5.0.
Thanks for any suggestions on how to make the tool support this operation.
Referring to your steps 6 & 7: In AccuRev 5.5 after a file is edited and has a (modified) status you first have to keep before you can promote.
At step 8 you could try doing the merge from the Browse Versions view of the file. That way you can select any node to merge with, including the one that has been moved.
Step 9. An AccuRev update will not run successfully if one of the files to be updated is (modified). This is by design. You can keep the file so it has (kept)(member) status then run the update.
David Howland
After contact with AccuRev support the answer is that the only option available is to copy the file to some temp directory, revert the changes, update the workspace and copy the file into the new location in the workspace.
AccuRev will at least tell you which files you have to copy since they will be marked as modified.
I could experimentally verify David's remark to step 9 using AccuRev 5.5.
Let's assume that in the workspace of user A the file was moved and the move was promoted, while in the workspace of user B the file was modified and user B is about to promote his/her change.
Before the file is kept, it will not be possible for user B neither to merge nor to update. But after keeping the modified file the update is possible. The file is first marked as overlap, then the merge succeeds in the new location. Basically, this avoids creating a copy of the file, reverting it and restoring it in the new location after an update, which can be quite cumbersome, as AccuRev does not reveal easily where the move goes.
If user B promotes the modification before user A promotes the move, all goes smoothly, i.e. on update the moved file appears as overlap, but easily merges into the moved file in the new location.
Similar results are obtained when the two users have workspaces connected to different streams and the overlap occurs on a common parent stream. Only if the file is unkept, an error can occur (i.e. only if the move is promoted before the change). Then a simple keep allows to proceed as usual (update, merge, then promote).
We are using Accurev 5.6. We run into a weird issue during promotion. One of our developers defuncted a file abc.txt in his workspace and promoted it to the backing stream under an issue. Then after a few days, he realized that he needed his file. He created a file with the same name and promoted it up under the same issue. Before the release, we tried to promote this issue to a parent stream. The Accurev complained saying the file abc.txt existed in the parent stream and prevented us from promoting it.
It looks like the Accurev promotion got the order wrong. It tried to promote the activity of creation of abc.txt first instead of defunct of abc.txt first. What Accurev should have done is to promote activities based on time of the activities: first, defunct the abc.txt in the parent stream and then create the abc.txt file again under a different element ID.
Is this an Accurev bug? Is there anyway to configure Accurev to promote based on time of the activities within one single issue?
This is not a bug in Accurev. This is a nuance of Accurev. Accurev gives each new element an id. This id is unique to that element and stays with that object as it gets defuncted, renamed, moved, etc. This is just how Accurev works, which makes it a blessing and a curse.
Steps to Resolve:
Rename the 2nd element the developer promoted.
Defunct this element.
Undefunct the 1st element.
Promote up both changes.
At this point, you can promote up abc.txt.
You can then purge (Revert to Backed) the defuncted (2nd element).
a. You would want to Revert to Backed in this instance because you probably don't care about that version and so it doesn't sit in the default group of your stream forever.
Search the online documentation for twin for more detailed information. Sorry I couldn't get a direct link.
Twins are a pain, but it looks like Accurev has been slowly improving detecting and fixing them. See the latest release (5.7).