I'm using Perforce to integrate two codelines. In the resulting changelist, there are files which are marked as opened for integration, but have not actually changed.
Should I submit these unchanged files or should I revert them?
I want to revert them because I don't want these unchanged files to pollute the changelist.
But, if I submit them, I have a feeling that Perforce might have a use of this "fact" (that the files have been integrated) for future integration.
There is no need to submit unchanged files. I can't even understand why the option exists. Perforce only needs to know about changes you make to files. The fact that you checked a file out, but did nothing to it, is irrelevant. Revert unchanged files. As you said, don't pollute the revision history.
Yes, you should submit them. This will create the integration record to record that the changes have been "integrated" (which may not mean actual changes occurred on the target).
I always reverted unchanged files in my changelists. I can't remember any wrong consequences.
(Fortunately, now we switched to git.)
Related
We use Entity Framework 5. Sometimes we find if we make a change to the model all class files are deleted and re-created, although most of them contain exactly the same code as before.
Subversion marks all these files as deleted/new and, when committed, uploads a new version of all of them, regardless of whether their contents have actually changed. This is annoying as it makes it difficult to track which files have actually changed.
Is there any way to make subversion include in the commit only those files that have actually changed?
We are using TortoiseSVN 1.7.11, Build 23600; and AnkhSVN 2.3.10838.1211 with Visual Studio Professional 2012
As workaround you can use subversion hooks and prohibit remove/add files with identical names in same revision. Then user will be responsible to convert 'replace' to 'modify'. This is also annoying, but will be better look in history, better merged and updated.
I worked with Windows Eclipse CVS and CVS did not allow me to overwrite the latest revisions – I needed to update first. At the same time one developer working on Mac constantly overwrote my files. We looked at this problem and found that his CVS Eclipse plugin allows overwriting the latest revisions without any warning.
Now I work with Mac myself using SVN Eclipse plugin and I accidentally overwrote the latest revisions from my co developer. How to prevent this overwriting? If this overwriting happens what is the graceful way of reverting to the previous revisions and committing them back to the repository?
Wait? Something is not right here...
CVS and Subversion will never let you overwrite someone else's changes. The whole purpose of version control is to allow multiple people to work on the same files at the same time.
There are two ways version control systems do this:
Checkout and Lock: The oldest systems used a checkout and lock system. That is, you checkout the code for changes, and no one else was allowed to checkout and make changes until you checked in your changes. The problem is that someone could checkout files for a week and forget to check them back in, or go on vacation. Then, everyone else is stuck unable to work.
Checkout, and first person who commits wins: In this system, two people can checkout the same file and do their work. However, the first person who finishes their changes and commits wins. The other person must do an update which will incorporate the first person's changes into their working copy before they can commit their changes. This is what Subversion and CVS do.
So, how in the world are you losing your changes? Or, how are you overwriting the other person's changes?
Sometimes this happens if you are sharing your checked out working copy with other people. This is wrong and should never be done. Instead, each user should have their own separate independent copy of the project (Heck, you can even have multiple version if you want). When your partner checks in their changes, it shouldn't affect your files.
What will happen is that when you try to commit your changes, you will be told that your working copy is out of date. You'll have to update your working copy and that will incorporate your partner's changes into your working copy. You should then verify that everything is okay, and then commit your working copy which will now include both your and your partner changes.
Does this answer your question? Are you sharing all sharing the same directory, or do you have your own working copy? Is there something else going on?
(I work with perforce from eclipse by the perforce plugin).
After associating my workspace with a perforce depot, all the files got status "Version in workspace is not latest version" (yellow triangle)....
When a file has this status, submit is disabled for this file.
When I do "Sync with depot" on a project, all those files show the conflict icon (even when there's no conflict...).
Conflict? does it mean I need to resolve?
Here is how to do resolve:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/05_resolve.html
The problem is... by "resolving" perforce overrides all the files in my workspace with the files in the depot. So every change I made to the workspace before associating it to perforce is gone.
What I actually want to achieve is the other way around: submit all the files in my workspace to the depot. i.e. override the depot.
How can I do that?
If perforce says that you cannot submit because "Version in workspace is not latest version", then this means that you have a file open for edit that was already changed and submitted by someone else, i.e. you're working on an old version of the file.
You definitely should not try to force your (old) version on top of the newer one in the depot.
You really need to resolve. Perforce will not "override" all the files your workspace and discard your changes.
For merging (resolving) you can use the eclipse built-in merge tool or the p4merge (from Perforce).
As other answers say, most of the time your best bet is to work with Perforce's workflow and check out the workspace in advance and make your changes there, rather than make changes first and create the workspace later. Sometimes, though, you really do need to break Perforce's workflow and override the changes in the depot. If you're going to do that, you need to be extra careful that you're not reverting something important. (Even on a one-person project you might have forgotten you checked something in, so look carefully at the diffs before submitting.)
The easiest thing to do is, when Perforce tells you that you have a conflict, resolve but keep your changes. In the Perforce documentation link, that's 'resolve, accept yours' rather than accepting what Perforce thinks is the sensible merge. From the command line, that's p4 resolve -ay. It's worded a little differently in the p4v GUI, and may be worded differently still in the Eclipse plugin (which I haven't actually worked with).
The other option, which you might use if you have files checked out from an earlier revision, and you want to update to the tip revision without making any changes, is to tell Perforce to update the metadata, so that it thinks you have a newer version of the file, without actually altering any of your files. From the command line, that's p4 sync -k (whatever you want to sync). This, too, can be dangerous if used inappropriately.
I don't think you can achieve what you want in Perforce. You will need to copy the files you've changed to a safe place and then resolve/revert all of the files to remove the conflict/out of date flag. Once done, copy your changes back and submit. It's a pain, but you should have connected with Perforce before making your changes.
What is the concept of each?
When is it ok to shelve your changes instead of checking in?
Shelved means the changes are set aside for you to work on later.
Checked in means that the changes are made available to the rest of the team, will be in the build and will eventually ship.
Very different. Think of shelving as a tool for context switching when you're not done with a task. Checking in means you're done (at least a part of it).
Shelve your changes when you want to save the changes that you have made, but need to go back to the previous version to make other changes (perhaps, bug fixes) that you want to deploy without the updates you are currently working on. Since you're usually checking in pretty regularly, I find this to be a rare occurence -- like I just deployed to the QA box and an error was immediately found. I'll shelve that day's changes bringing me back to the QA deployed version, make the update, then unshelve my changes -- merging the two as necessary. Any longer than that and you'll probably be looking to check out a previous version and branch instead. I'd be happy to hear of other experiences where shelving has proved more useful, though.
Other users can download your shelvesets by searching for them, so it is a good way to pass code around for reviews. however you will get an error if you try to unshelve code files that you already have checked out, so you need a clean environment ready.
I often shelve my changes at the end of the day if I'm working on something big that I can't check in. That way, if my PC dies overnight, I've got a backup on the server.
Darcy gets it spot on. You can also think of shelving as a private branch that is not publicly visible for the most part. Shelvesets can also be deleted completely, not like deleting checked in code. If you delete a shelfset it is gone forever.
Everyone above has said so much true and I learned allot from it.
Just to add my experience, correct me if I am wrong. In a project, we have a configuration file mypc.json specific to each PC of the developer. We usually override it when running server locally. Other team members have the same file name with different configurations in it. No one wants their file to be pushed with the same name to the development branch. So I use shelve to save these type of changes. Whenever I need these configurations I can easily apply changes from shelve and my environment configurations are back in my project.
I have a file I need to move that's already under perforce. Once moved it needs some editing - update the package, etc - appropriate to its new location. Should I submit the move changespec and then reopen it for edit, or can I do this in one go? If so, what is the appropriate sequence of events?
I have done this before in one go, but depending on your build process, I recommend against it. What I generally do is this:
Move the file.
If the move needs a change in order to compile, open it for edit and make those changes.
Submit the changes, telling perforce to reopen the files for editing.
Make the changes for path, etc., that don't cause compile errors but should be updated.
Submit those changes with an appropriate description.
If you want to, however, you could just do all your changes in step (2) above. Perforce might change the flag for the new file from integrate to add, but it still remembers the source path for the file.
Edit: Better method
I realized that I often use a different method, but the idea of "moving" the file distracted me. So, I would recommend these steps instead:
Integrate the file into the new path/name, leaving the previous file there. I am assuming that this won't break your build process.
Submit the new file, checking it out again for edit after submission.
Make the required changes to the new file, and to the project so that you are using the new file.
Submit the edits for the new file.
[Optional] You might need to check through branch specs to see if you need to map the old file into the new one in any branches.
Create a changelist for deleting the old file, and submit it sometime later.
This method allows the edits to be cleanly separated from the rename/move, while never leaving the project in a state that won't compile.
Also, why wait for step 6? Sometimes, especially on bigger projects, you might want to move a file that another person is editing. Perforce will helpfully tell you this. By waiting to delete the file, you allow your coworker(s) to finish the edits and submit without needing to move their work manually. After the edits are submitted, they can be integrated into the new file, and then the old one can be safely deleted.
Submit the move change and then reopen for edit (you could use the reopen option too).
This is much more readable to the user in the change history.
Also, recent versions of Perforce do perform checks for changes to files after resolution. So, there may be complaints editing files after some resolve operations have been completed.
I would say always submit first then edit. It is much cleaner and makes it more obvious whats happening in your repository. Then simply checkout the file in the new location and make whatever changes. This also makes it much more obvious that the changes were made in the new location and to all it to work after renaming.
Yes you can. Simply reopen for edit the branched file (i.e. the new one). In P4Win, there is a context menu for this ("re-open for edit").
"Safely" is probably an important point here. Once you rename or move the file it'll get a revision number of "1" which looks like a new file to your Perforce client. Of course, admins will be able to get its prior history, but if the editing/version history of the file is important to you it's a little harder to get the older revision.
Update: Thanks to Commodore Jaeger and Greg Whitfield for enlightening comments.
This wasn't easy to track down regarding what the One True Answer is, even from Perforce support, so I figured I'd update everyone on what we found:
Perforce stores all versions of every document in its database.
If it's saving your file as type <text> or <ktext> then it stores the diffs of one file version to another and not the entire file.
If you check out a file, make no changes to it, and then re-submit, it will save as a new version with 0 diffs. This is configurable and P4 can be set up to ignore changelist items without any actual diffs. You can force this behavior by selecting "Revert unchanged files..." before you submit a changelist.
Use "Rename/Move..." to move files in P4 so it can track them. Don't copy them using Windows Explorer and then re-add them in P4.
If you use the "Rename/Move..." function from the context menu, the "new" file will show a revision number of "1" as though it were a new file.
However, since P4 saves every function performed on a file, you can actually get to any previous revision (and even recover "deleted" files) with the CLI command p4 filelog -i
If you want to get to the revision history of a moved or renamed file and you're not an admin, you can right-click and select its "Revision Graph" which shows every version of a file even when moved between branches.
According to Perforce support, easier tracking of revision history through branch or folder moves is an oft-requested feature and is in their current roadmap.
Perforce's answer: At the moment, there isn't a way to move/rename/integrate files and still maintain the exact file history.
However, if you were to choose "Integrate..." by right-clicking on the folder that you want to share, the versions of the files of the newly branched folder and underlying files will start from revision #1, but the integration history between the branched folder and underlying files and the original folder and underlying files will remain through which you can trace the revision history of the files.