I am new to this and facing some trouble while checking in my code for the first time.
I have a bunch of opened files in my client. After making my changes, I did a sync to sync my client to depot. Then I did p4 resolve to resolve the changes. Now, for some files, I had few conflicts. I mistakenly messed up those files and I am not sure how my version is different than the most recent checked-in version in the depot. So, this is what I was trying to do...
Sync back to a previous change list, then again do a sync to the HEAD and do p4 resolve- however now it's saying there there is nothing to be resolved.
I did a p4 revert to revert my changes, then again modified my files and did sync-> resolve. However again, I'm getting "nothing to be resolved" message.
I am using p4 command line. How can I get back to my old state and resolve the changes?
If you originally made the changes on your local machine and didn't submit them to a branch or shelve them, then you probably wiped out the state of those changes when you ran p4 revert (if not before).
If you then synced back to the HEAD and manually redid your changes at that point, then there's genuinely nothing to resolve because you already had the latest revision from the depot before you made your changes.
I would advise checking that your pending changelist has exactly the changes you want and nothing more, either by right-clicking and choosing "Diff against have revision" in p4v, or using p4 diff from the command-line. If there's nothing unexpected in there, then submit those changes.
Related
I've used a number of version control systems over the years, and would say I've mastered SVN and Mercurial, but now I have a contract which requires me to use perforce. I have the basics under control, but occasionally I find an area where it's not clear exactly what perforce is doing.
Shelving changes is one of these.
This week I was in a situation where I was in the middle of a piece of work, and needed to change focus and work on a quick fix for someone. The old work was based on an older revision, and for the new piece of work I needed to be at the latest. So I...
Shelved my current changelist.
Updated my workspace to the latest revision
Did my work
Submitted it.
Unshelved my original changes
I knew I was at the latest revision when I unshelved, but "That's OK, I needed to update anyway". What surprised me was that I didn't need to resolve any files. Unsure about why that would be I...
Reverted my workspace
Updated to the revision I'd originally been working at
Unshelved my files again (I hadn't deleted the shelved version)
Updated to the latest revision
At this point perforce asked me to resolve files, and it wasn't a trivial resolve (i.e. not one that could have been done automatically).
This has left me with questions:
Is shelve just copying a file out of the way, and then copying it back? or is it storing a delta?
Is it possible to cause other's changes to be undone by using shelve?
How should I be working when this situation arises in the future?
p4 shelve saves your files on the Perforce server, but doesn't remove your pending changes from your current workspace. After issuing the p4 shelve command, you could have issued a p4 revert command to restore your workspace to the unmodified versions of your files, but from your description, it looks like you didn't do that.
So your update to the latest revision step (p4 sync) brought all the unopened files up to the head revision, but left your opened files as they were before you shelved them.
Your unshelve command had no real effect, since the files were already in the state you left them in before you shelved them.
As to your questions:
shelve is copying the files (probably as a delta, but it's not important to me as a user) to a place where you (or your coworkers) can get them later, but it's not "out of the way," since it doesn't automatically revert your shelved changes in your local workspace
shelving itself doesn't change the head revision of the file in Perforce; it's more like a micro branch. However, when you unshelve a file, you may have to integrate the changes you made before shelving the file with changes that have been made to the file since it was shelved. This can lead to others' changes being undone if you're not careful.
Strenuously.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do I return to an older version of our code in Subversion?
I was looking at the diff in the commit window on Eclipse (with subclipse) and tried adding a line (by hitting enter) but instead committed by changes without a comment and without me making sure I wanted to commit the things I changed.
This added a commit with no comment and with changes I wasn't sure of to the remote repo. I checked out the previous revision and committed those changes over the commit I made accidentally.
So now HEAD is the same state as the revision before my accidental commit, but I would like to properly commit my changes now. I'm not sure how, though. When I switch to the accidental revision (to get my changes back), it doesn't let me commit because it says nothing was changed. I'm guessing it's comparing my local files to the revision I checked out, but I need it to compare it to HEAD.
What can I do here?
You could (svn) export your accidentally committed revision over your working copy. Then you can make your adjustments and commit your changes.
On the command line:
svn export -r <your accidental commit> <working copy directory>
In Eclipse:
right click on the accidental commit in the history view
select "Export..." and choose the directory containing your working copy
The easiest thing would be to make a unified diff of the revision you committed and then use the Apply Patch option to reapply it to your workspace.
You can also just do Show History on the changed file. Then find the revision, select the file in the appropriate pane, and choose the Get Contents option. This will make your working copy version of that file match the contents of that file in the selected revision.
In either case, your working copy should now show as dirty and you can review and commit when ready.
I ended up reverting the changes from the very last commit I made and then re-committing those after checking everything.
I want to test a fix and to compare the behavior before the fix vs. now; I need to sync to a the earlier version. So, if the fix was committed in revision x; how can I sync to one revision before, say x0?
Say that you want to go back to revision 'n' from revison 'n+1' (rollback). You can take the following steps:
p4 sync ...#n
This will sync your files to the older version that you want
p4 edit ...
Open all the files for edit or do "p4 edit filename" to open only a particular file for editing.
p4 sync ...#n+1
Before submiting you need to sync files to the latest revision on the repository.
p4 resolve -ay
This will accept the changes that you have made, ie, revert all the changes done when you moved from revision 'n' to 'n-1'. So effectively, all your files have been rolled back to revision 'n' in your local repository.
p4 submit ...
Go ahead and submit the changes. This will roll back all main repository to revision 'n'. Effectively the revisions 'n' and 'n+2'(current) will be identical.
p4 diff2 -q repository#n repository#n+2
This is just to verify if have rolled back the files. This should show that you have no differing files in the two revisions.
I found the answer while writing my question. I have been trying:
p4 sync ...#x0
where x0 is the changelist before the change containing the fix. But only a fraction of files was getting reverted. I found the issue that when we specify ... only the files in that folder and subfolder(s) get synced. So above command should be executed from the root of the workspace.
If you want to sync a specific version number (not changelist number) for a specific file. This worked for me:
p4 sync //your/depot/path/and/file.name#1
to verify you have the version you want, you can use the have cmd
p4 have //your/depot/path/and/file.name
I have seen behaviour in Perforce that I am unable to explain. I took a branch of the trunk and worked on this regularly committing my changes and occasionally merging from the trunk to my branch to ensure there were not going to major conflicts when I reintegrated.
When this work was complete, I used the Perforce Merge/Integrate option to apply the changes to the trunk. After sending these changes for code review, I made some changes on the trunk. At this point, none of the changes had been committed to the trunk.
When I went to commit all of these changes, the diff showed the files exactly as I would expect. After submitting the changelist, the changes which were submitted were not the same as what was shown in the diff window. Instead, the changes that I'd made since the Merge/Integrate were not there. Doing a diff between the server and my local copy on the trunk had all of the changes to the same files made after the code review. As such, I had to do a second commit to mend the broken build.
I'm confused how this happened as I thought Perforce only kept one local copy of each file on the client?
Even if there is a flag showing the files have been tampered, where were the files it submitted? It definitely showed the trunk paths in the commit window, but I guess it could have got the files from the branch?
Another question would be, how should I have best dealt with the above scenario when using Perforce version control?
One mistake we've all made is to (a) integrate a file from one branch to another, (b) resolve it as "accept merged", (c) make local changes to the file prior to (d) submit. If you don't explicitly open the file for edit after step (b) and before step (c), the server has no knowledge of your local changes.
You made your first mistake editing things directly on your copy of trunk. Always use a task branch. It probably didn't cause the issue you were seeing, but if you'd messed up your task branch it wouldn't have broken the build. When looking at your local copy of trunk, ensure you've refreshed it from the depot. You'll get little yellow triangles if your local copy of a trunk file is out of date, editing and committing an out of date file on your copy of trunk is bound to lead to "odd" behaviour.
I'm confused how this happened as I thought Perforce only kept one local copy of each file on the client?
One copy for trunk, one copy for each task branch.
I am using Flash Builder for PHP 4.5 to work on a php project. It is essentially Zend Studio which is built on top of eclipse.
I've moved some folders and files, renamed some files from within Flash Builder. Some files were also removed. I then attempted to commit to SVN.
SVN comes back with an error saying commit failed as one of the files is not up to date. Conincidentally, this is also one of the files that was removed.
I then proceeded to do an update first and got the message: No changes to merge.
Trying to commit again just results in an error saying that the files are not up to date.
Any ideas as to how I can fix this?
Assuming that it's the deleted file that's making your commits fail, you can try reverting the deleted file, then updating, then deleting again, but if that fails, you might want to consider making a copy of the changes you made in your WC, revert the originals, update the originals, then copy all the changes back.
OR, if you're sure that it's only that deleted file that's making the commit fail, then commit everything else first, then go back and revert the deleted file, update, then delete and commit again. Like I said, SVN is fickle about dirty working copies...