My company uses Accurev for source control, and for all its benefits, there's one simple action that I just can't figure out how to accomplish.
I wanted to promote an issue#A from Development stream to UAT stream. But issue#A am trying to promote has dependency on another earlier Issue#B. Now when am trying to promote issue#A am getting “Operation Failed: merge required for Element: xxxyyy.java.
Please help me in how to promote issue#A to UAT stream from Development Stream
First, It sounds like the file xxxyyy.java is in an overlap state and needs merging, thus the error.
If issueA has a dependency on issueB, you should probably promote both issues as there is a common file between the two issues.
Example:
Keep and promote file1 -> associate issueA
keep and promote file1 -> associate issueB
You can promote issueA by itself as the version of file1 is 1.
You can not promote issueB by itself as the version of file1 is 2 and it contains version 1 (issueA, the dependent issue.)
Related
Is it possible to create branches in Perforce in a similar style to Git? I.e. without creating a new folder.
I would prefer for my client to manage the branches transparently whilst I work against a single copy of the directory tree on disk.
It seems awfully wasteful for the client to create an exact copy of the entire tree if you're only modifying say a couple of files. I much prefer Git's workflow in this regard.
If it's not possible using straight Perforce I'm happy to move to GitSwarm.
For info I'm running Perforce version 2015.1/1233444.
Possible yes, but with the centralized version of the system it involves a bit of 'magic'. Basically, the branch part doesn't need to involve the client at all anymore. Take a peek at p4 populate. That'll create another folder on the server, but won't do anything locally. Then you can edit your client workspace to map the branched files instead of the trunk files, and it'll just re-sync over top the files on your disk.
Now, having said that, if you wanted to take a look at our DVCS version of working, then you can just do "p4 switch -c " and it'll create a new branch locally, switch your workspace over to it (shelving any open current work in the process) and away you go.
My original answer was deleted because I thought a link was a better idea than repeating content. My mistake.
At any rate, I believe the DVCS features in Perforce Helix supply exactly the sort of thing you're after. In a blog I wrote in the subject (link here for reference) I explained how to create a new in-place branch with a single command:
p4 switch -c newBranchName
That will create a new branch with the name "newBranchName" and save any existing work in progress by default. To discover on which branch you're working you can use the switch command with the list argument as follows:
p4 switch -l
That would show you output like this, the asterisk showing that you're now working on the newBranchName branch.
newBranchName *
main
You can switch back and forth as you like, changing contexts as needed as often as you like. Your work in progress will continue to be saved on each branch in progress. When you're ready to merge your work back to main and push it back to the server, you can use the following sequence of commands:
p4 switch main
p4 merge --from newBranchName
p4 resolve –as
The first command switches back to the main branch, the second merges your work from the newly created branch into main, and the third resolves any potential conflicts automatically. If there are any conflicts that can't automatically be merged, then you can use the usual commands to walk through the resolution process.
Alternately, if you prefer to stick with Git, you can use that directly with our Helix Versioning Engine through our Git Fusion technology or use Git directly with our new GitSwarm technology. That is a pretty amazing option (in my opinion) as it makes it possible to mirror content automatically and bidirectionally between GitSwarm and the back end server. That way you get all the features of Git with GitSwarm (which itself is based on GitLab) and all the goodies from the rest of Helix.
Hope that helps!
If you use streams (Perforce's "managed" version of a branch, as opposed to doing completely ad hoc inter-file branching with arbitrary paths), it's pretty simple. As P4Gabe said, "switch -c" is a one-shot option on a local server.
On a shared server it's only a little more complicated because you have to do the "populate" explicitly (this is to keep naive users from accidentally branching lots of files lots of times on a shared server), but it's still only a few steps and it's something that you as an advanced user could script easily:
p4 stream -P (current stream) -t development (new stream name)
p4 populate -r -S (new stream name)
p4 switch (new stream name)
The equivalent is possible using ad hoc ("classic") branches as well if you have a good understanding of how client views work -- use populate to create the new branch, modify your client view to map the new branch into the namespace currently occupied by the old branch, and sync.
This blog post on what exactly "p4 switch" does might help if you're trying to engineer your own solution that's similar-to-but-not-quite the "switch" command: https://www.perforce.com/blog/150428/p4-switch-switching-it
I am looking for best practices using branches in RCS.
I had read the man page for rcs and ci and also browsed at the following links:
http://www.gnu.org/software/rcs/manual/html_node/Concepts.html
http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html
Suppose i have revision 1.3 on tip of the trunk.
I now want to change file 1.2 (as 1.3 have several other changes I cannot yet use).
I understand I can create branch on revision 1.2 using ci -r1.2.1
My question are the follows:
1. Do I need to set a lock on the file? If so, on which revision?
2. If no lock set, I cannot use -u flag in order to keep the file in my local dir. In case I wish to do so, is it still possible without co the file again?
Side note: I feel RCS does not suit my company needs however migrating to another system is not my decision to make, so currently I need to keep working with it.
I'm looking for much the same thing, but seeing you've had no answers, I'll offer my current practice:
I use branches for development, not for keeping different variants going in parallel. The trunk is reserved for my best, presumably working, code on the and I try not to check in anything there that might break it. I branch the code when I want to start a line of development that will take some time, break it for a while, is an experiment I might have to be abandon, etc.
To start a new line of development I change the default branch to a new branch off the trunk rev that's to be the base of my code, and force a checkin onto that branch, with:
rcs -b1.2.1 foo.cpp
ci -f1.2.1 -l foo.cpp
Now I can dive in to developing the branch, and my next check-ins will go onto the new branch instead of onto the trunk. Whether you lock a revision or not is only relevant to whether you intend to modify the working file.
You're correct that you can't keep both revisions, trunk-tip and branch-tip in the same folder; they have the same file name. But you can check out one of them with a -p switch which forces the output to stdout (instead of to a local file) which you can then redirect into a sub-folder, or to a local file with a unique name.
My colleague and I are participating in a huge project located in Accurev. We've already created own workspaces backed with some stream (let's call it zzz-stream) which is used by many other participants, not only by us.
The point is that we want to exchange our work between our workspaces, make some changes, exchange again, etc. BEFORE making the changes accessible for others, i.e. in other words we don't want to propagate our changes until it is stable and tested, but we want be able to work on it together.
My idea was to create new stream (yyy-stream) backed with zzz-stream, and then change our workspaces to be backed with yyy-stream. But unfortunately I have no rights to create streams.
My second idea was to use a workspace as backed stream, but it doesn't work because Accurev can't use ws as backed stream.
Is there any solution for our problem?
UPD: I accepted Brad's answer as most detailed. However Accurev is too heavy and sluggish to be used effectively. So actually I prefer to use Git for internal needs over the accurev workspace. (see Accurev externally, git internally)
Your idea of creating the yyy-stream is the EXACT right way to do it. The other options are decent workarounds for one-off situations, but creating the extra stream is simple and is fully leveraging AccuRev's capabilities.
That being said, I understand that your admins have stream creation locked down. They of course want control, but should be allowing for maximizing developer productivity and not forcing workarounds like this. My guess is they have stream creation locked down to a particular group being enforced by the server-admin trigger. One common thing I have seen other large sites do is:
- allow streams to be freely created off of a list of acceptable streams (easy to do in the trigger)
- enforce naming rules on the stream creation. This is important to admins in large sites to keep things organized. Again, this is very easy to enforce via the server-admin trigger.
Bottom line, if this is a common situation, work with the admins to allow this capability as per the above. If they have any questions, they are more than welcome to contact AccuRev and we will help them out.
Your idea on using another stream for you and your peer is a good one and is commonly called a collaboration stream. If your site has stream creation locked down, you would need to work with your AccuRev administrator to make that happen.
Another option is for you and the other developer to pull the keeps from the other workspace into your own stream. This relies on both of you being diligent about doing keeps and then you can look at the history of the other developer's workspace to find the keep operation, right-click that transaction and then select Send to Workspace. The destination workspace must be your own.
A third option (more for a situation where you are in your workspace and know exactly what file you want to grab the other users changes)is to bring up the version browser for the file, right click and select history/browse versions. Look for the other workspace, highlight the version in that workspace, right click and select send to workspace. This will checkout that version into your workspace.
This is similar to the change palette suggestion but quicker if your looking to this on a file basis.
Another idea is to use different version control system (e.g. git or svn) over Accurev workspace to exchange the changes and keep our history separated from zzz-stream. (similar to Accurev externally, git internally) Only changed files should be added to other VCS, not whole project. Some merge problems occur though.
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).