This question already has answers here:
How to revert / undo unchanged files in TFS?
(5 answers)
How do I know which files I actually changed since my last TFS checkout?
(3 answers)
Closed 9 years ago.
I worked some hours when tfs server was unavailabe. After go online and getted new sources I have 1900 files with empty pending changes plus my 10 files with really pending changes. It is possible to undo only empty pending changes by several cclicks or some script?
If you try to undo changes when there are some, you will be warned; when there aren't any, it'll silently succeed. Similarly, if you try to commit a "no change", the file history doesn't update, and your file is no longer checked out. Therefore you've two options:
Try an "undo all" and cancel the undo on the files you want to keep the changes in.
Commit the unchanged files alongside your changed ones. And have them silently undo. (of course, if you do code reviews, your reviewer might not like you for this)
Related
I've tried searching for answers to my problem but every thread starts talking about branches and trunks and I have no idea what they're talking about.
I'm in a team of 2. We've started working on a single excel spreadsheet. I use SVN update before making my changes, however while I'm making changes, my team-mate also makes changes and commits them before I do.
I was first told that I simply have to update again before I commit and it should merge my team-mate's changes with mine. However when I update the .xlsx file, nothing seems to happen. I open up my local copy again and it isn't showing my team-mates changes. I've tried using the merge option and clicked random things in numerous attempts but nothing works. Nothing I've tried will add my team-mates changes to my working copy. Every time I compare my working copy with the repository, the changes from both of us are all highlighted, but nothing I do seems to merge them together.
The cells we modify in the spreadsheet are different ones, so we don't both make direct changes to the same cell. It should be a simple merge.
This is driving me up the wall, it keeps saying "merge successful" or "update successful" but it isn't doing anything.
.xlsx files are not text-files (they are really zip-archives), don't expect merging of such files from Subversion in any case
You can't have easy teamwork with Office's documents
First of all, xlsx files are binary rather than textual so SVN cannot merge them very well. So two of you working on one such file at the same time will not work well even if nothing goes wrong.
As for why you never saw the changes, probably you still had the file with your changes open in Excel when you did your update, and Excel never prompted to load the new changes.
To correct the immediate situation you can move your version of the file elsewhere, svn update to get the repository version back, and manually compare and resolve the differences.
In the future, since SVN is not suited well for merging this type of file, set the svn:needs-lock property on this file, and always be sure to svn lock it before editing to keep your coworkers from making changes at the same time.
If you need simultaneous editing capabilities, look into what cloud services Microsoft offers, or switch to Google Docs or similar.
This question already has answers here:
p4v does not show the complete list of checked out files
(3 answers)
Closed 8 years ago.
A coworker submitted a gigantic changelist (>1000 files) as part of a refactoring, and perforce just shows it as 'There are 1000 files in this changelist'.
I'd like to see the changes he made to all files in a folder/module via Perforce p4merge or IntelliJ's perforce integration/diff tool.
In P4V go to Edit->Preferences and select "Server Data" settings at the left.
Increase setting "Maximun number of files displayed per changelist*:" to desired value (e.g. put more than 1000 for the example above) and save settings.
*After limit is reached, changelist and resolve dialogs show plain text list of files
I am using Windows 7, perforce 2010.2 Yellow client.
I was trying to mark some 6 files for deletion. But accidently, it marked the entire depot for for deletion (could be my mistake).
But strange behavior is it marked for delete in less than a second (more than 1,00,000 files), but reverting took more than 5 hours.
Does anybody know how it works internally? Or any guesses?
As James said, the p4 delete removed all 1,000,000 files. Reverting that requires the client to re-download all 1,000,000 files.
I am using the Perforce P4V client (version 2013.1/611291, dated 2013 March 20).
I attempted to Merge/Integrate from the main branch to my feature branch. It had been a long time since I had done this, so a significant number of files were added to the changelist. I then resolved conflicting files that could not be merged automatically. I then submitted the changelist. After doing that, I discovered that some of the files had remained in a messy conflicting state. Exactly why is a mystery to me, but instead of trying to fix them, I thought it would be easier to just undo the Merge/Integrate entirely and start over again.
To undo the Merge/Integrate, I used the 'back out' option. All affected files were added to the 'back out' changelist and I submitted it. My feature branch is now back where it was to start with, except obviously by now all affected files have had their revision number bumped up twice, and the history for affected files shows the integration and then the subsequent 'back out'.
The problem is that if I try the Merge/Integrate option again, this time round the number of files that Perforce wants to put into the integration changelist is now a fraction of those it originally tried to integrate. Put another way, it's not adding lots of files that I know are most definitely further forward in terms of development in the main branch.
The only way I seem to be able to get around this is to use the advanced option Force integration on all revisions, disregarding revision history (-f). With this option set, it will then add for merge all files from the branch.
I suspect the problem is something to do with the fact that the files now have an integration marked in their history, and therefore Perforce is using that point as the base. The fact that the messed-up integration was 'backed out' doesn't make any difference to that.
I tried to do a rollback as well, but the same problem remains.
How can I solve this?
Edit
I have later realised that there is the following similar question:
How can I undo an Integration in Perforce, and still be able to redo it?
The files which you're trying to integrate from the main branch to your feature branch have an integration history after your first integration check-in.
When you backed out the changes, you got your feature branch's files to the state where it was before the integration, but new versions of the files were created for each of the file in that previous changelist.
The next integrate hence tries to bring in ONLY the difference in the integration path since last time.
As you've mentioned already, the only way out of this situation is to run a force integrate using the -i. You can still resolve the changes using p4 resolve -as ... and p4 resolve -am ... just like last time, and then hand resolve the remaining conflicts to perform the merge. Except that the history would show 2 extra versions of the files changed in the prior merge commit and the commit for backing it out.
If you're okay with creating a feature branch at a different location and discarding the one at your current location, you could set the starting point for the new feature branch to be the commit/changelist just before you performed the problematic integrate.
Integrate from your main branch into the new feature branch and you should have a much cleaner history this time and should have all the file changes (with history) you've made in your original feature branch as well.
Unlike other version control systems (like git for example), it is unfortunately not possible to rewrite history in perforce to make it forget about the integration history and start fresh again.
This is one of the reasons in my company, all the architects and SCMs are very much picky and reiterating their workflow advice, about strictly following integration paths between branches when performing integrations using perforce.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to find untracked files in a Perforce tree? (analogue of svn status)
I want to know what p4 command that will show me which files have changed, which files are not checked in, etc.
If you're using perforce properly, "p4 opened" is what you're looking for. It will tell you what files you have opened for change. If you want to be able to change files locally, THEN open them for edit (or delete, etc.,) then you're walking out of the usage patterns that perforce expects users to abide by and you're treading on dangerous ground.
Perforce does provide mechanisms that will allow you to detect these things - if you're going to insist on working this way. "p4 fstat" will allow you to get the expected md5sum for a file from the server. Comparing that with the local md5sum will tell you if the file has changed. You could, alternatively, compare file dates - if the modification date on your local machine does not match that given by fstat, you can be fairly certain that it has changed, but to be certain, you'd have to do the md5sum check.
In the upcoming 2012.1 release there a new command named p4 status that will do the equivalent to that as if you were using SVN.
p4 status
src/tools/this.rb - reconcile to edit //depot/stuff/src/tools/this.rb#3
src/tools/that.rb - reconcile to add //depot/stuff/src/tools/that.rb#1
src/tools/other.rb - reconcile to delete //depot/stuff/src/tools/other.rb#2
For more information, read the announcement on the Perforce Blog.
While awaiting the official 2012.1 release you have basically two options:
Do it yourself using the command line
Use P4Vs "Reconcile Offline Work"
More details can be found in the Perforce KB.