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
Related
I've done this several times in git, but not sure how to do it in p4 commandline. Google is not helping me - or maybe I'm not searching correctly.
I have a file that was deleted: /path/to/file/index.html Now, I need to get the contents of that file as it was before being deleted. I do not want to bring it back to life, I just need the contents.
The changelist for the delete is 125325.
What would be the easiest way to do this?
To sync it to your workspace (this is kind of similar to the git checkout method that you're probably familiar with):
p4 sync /path/to/file/index.html#125324
If you just want to see the content (e.g. dump it to stdout), you can use p4 print (if you were to use the depot path of the file rather than a local path, p4 print doesn't require that the file is mapped to your workspace):
p4 print /path/to/file/index.html#125324
Note that the rev specifier I'm using is the changelist before the file was deleted. You can also use the prior revision number, or an earlier rev/changelist, a particular date, etc. See p4 help revisions for all the ways you can reference older versions of files.
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.
There is a repository repository repo.fossil
bug.c modified many times (eg. revision 10a3->34bd->152c).
There are many files changes in 10a3, 34bd and 152c revision.
Bug will fixed if combine 152c revision with bug.c at 34bd.
How to keep such version, I use following command but failed?
fossil open ~/fs/repo.fossil # contains many files
fossil update -r 34bd bug.c
fossil ci <-- why there is no change?
This seems to be two questions packed into one
1 Why is there no change.
There is no change because you have not made any changes. You have have opened ( copied into the working directory ) the file that belong to "old_revision". You have not changed anything It remains identical to the file for the version as stored in the repository.
2 How to revert a particular file
fossil open ~/fs/repo # contains many files
fossil revert-r <old_revision> one_file
fossil ci
Notice that I am using the revert command, NOT the update command
Here are the details of the revert command http://www.fossil-scm.org/fossil/help?cmd=revert
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.
I am trying to rollback to a previous version of the file/folder Settings.bundle. A file was added to Settings.bundle/en.lproj. If I just delete it I just keep getting missing file warnings (and I don't want to). So now I am trying to rollback, but it seems to do nothing when I try to run the command:
svn merge -r 15:5 ./Settings.bundle/
Any thoughts?
Should work so far according to Undoing Changes in svn red book. Maybe it's worth trying to run svn delete on those files added since revision 5 (sounds like you don't need them any longer), commit it and perform svn merge again.
Alternatively you can do it manually by running svn export of the Settings.bundle to a temp directory. Afterwards svn delete on all files added since revision 5 and copy files from temp dir back to your working directory. Now you are ready to commit revision 16.