When p4 submit containing multiple files fails due to a conflict in a particular file, is any other file successful submitted to the remote depot?
No. This is the entire reason that changelists exist:
https://www.perforce.com/perforce/doc.051/manuals/p4guide/07_changelists.html
When you submit a changelist to the depot, the depot is updated atomically: either all of the files in the changelist are updated in the depot, or none of them are. This grouping of files as a single unit guarantees that all files grouped together in a changelist are updated simultaneously. A Perforce changelist is an atomic change transaction.
Related
I've already done a large integration of several hundred files and have this all ready to go in a pending changelist. The problem is my depot is streamed and my workspace is non-streamed, aka classic. Since our P4 server has both streamed and non-streamed depots, I didn't realize that mixing them would be an issue and stuck to what I know, the classic style. However, when I go to submit my changelist I get the dreaded "warning: cannot submit from non-stream client".
So the first thing I tried to do was add the stream to the workspace in P4V and that succeeded. The mapping for the stream is very similar to the mapping I used in my classic workspace. The client didn't raise any red flags or warnings during this operation. Except now my pending changelist shows as having 0 files in it. Not good. So I drop down to commandline and use p4 describe. It shows my changelist how I left it with the files intact.
Since the commandline seems cooperative and p4v doesn't, I decide to just submit from commandline except when I try that I get "Submitting change <#>. No files to submit."
Ok...so I'm new to streams and not sure how to go about getting these changes submitted. Any help would be appreciated :)
One general-purpose solution to this type of problem would be to shelve the files (and revert the local versions) before you modify your workspace. After you've messed with your workspace (changing the view or stream or what have you), you can unshelve the files; if the view has changed the unshelve operation will automatically put the files in the right places for you.
(Since you've already changed the workspace, a little more troubleshooting might be needed to figure out exactly what state you've ended up in and how to get out of it -- I'd recommend contacting Perforce support or posting on forums.perforce.com.)
I have a simple structure in TFS. Something like this:
[Main]
|
---------------
| | |
[Br1] [Br2] [Br3]
The code is merged from Main to Br3 has been worked with in Br3 for a while.
Then one merge happened from Br3 to Main with a few conflicts (about 15 files) and once trying to check in on Main branch I get a huge number of files marked as changed to be checked in. I assume those are all the files in the Main branch. When randomly comparing some of the marked ones, there is no visible change between to two (even if displaying white spaces).
Anyone knows what happened here?
EDIT
How do I find out if the change would only be in the file access rights between my local and server file, and how could I ignore those kind of changes?
According to your comment. Since you are doing a baseless merge. Then its a normal phenomenon. When you did the baseless merge, every single file in the solution was marked as changed and listed in the pending changes during check in. There is no option which you can simply ignore those kind of changes.
Did you mean you want to find out 'the real changed files'?
You can try below workaround undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left. from this question Files listed as pending changes when doing merges that didn't change?
Note: This works when you only have changes to files. It will not merge any New files that you have added.
I have a branch created some time ago in TFS of our main trunk branch. I've periodically been merging trunk->branch to keep it up to date and now I'm ready to push back to trunk.
I have modified about 10 files in 3 projects, however when doing the merge TFS marks 7000 files as modified, seemingly every file in the branch. I can see that the files are nor modified in every case I check but I don't dare check them in without checking every file and clearly that's no good in this case!
In the Source Control Explorer view, all these files and folders are marked as "merge" in the "Pending Change" column.
Can I fix things somehow or do I need to undo the merge and manually merge only the files I know I actually modified, breaking the whole point of merging?
Reasons for this might be one of the listed items in Why are all files marked with 'merge' in TFS?
But there are other cases as well:
Another branch of the target branch had itself a branch that was renamed then merged to the child branch then that child branch was merged to your target branch;
There was a move or rename of your branch and it was rolled back (but you can see it in the changesets still);
The way I solved it was to do a merge using the "Selected changesets" instead of "All changes up to a specific version". Then in the following dialog, exclude the renaming attempts.
Once this is done, you will still have these changesets in the history bugging you for every merge, so you might want to discard them with "tf merge /discard".
I have a customized build process that sets the build name to the current version, updates the FileAssemblyVersion, drops to two different folders, and removes all unessential files from the drop folders, and I'm feeling that I'm starting to get the hang of custom actions and the workflows now.
So now I want to include a changelog in my drop folder; the Changeset comments. Either only the Changesets associated with this build, but possibly all changesets from a given changeset (such as a version number change, or another event).
What is the best way to approach this?
The Codeplex project TFSChangeLog can help you. From a command line you can create a XML file. Using XSLT you can create an output file of your choice.
http://tfschangelog.codeplex.com
I'm trying to find a way to merge shelve changes with the latest version I have locally without overwriting my local files with those of the shelve.
That is, I have a shelve from date 0, on date 1 some changes were done in the tree, on date 2 I do a Get Latest Version, then when applying the shelve, changes of date 1 get lost.
No merge conflict between changes in date 1 and those of my shelve.
Ideas? Thanks!
Finally, what I ended up doing was to
1) "get specific version" to the date when changeset was taken
2) "get latest version".
That way, TFS merges latest version with changed local files. (The other way around -what I was looking for- seems not possible).
Two options spring to mind:
(Advice: Before you start, back up your code, in case there is anything in there that isn't safely stored on the server or in a shelve set!)
If you unshelve first, you will end up with locks on the shelved (0) files.
Then GLV to get the (1) files. All the files you have locked will be merge conflicts, which you can then resolve, test, and check in as normal.
Get the shelved code and copy it to another folder on your hard drive. Then GLV the latest server code. Check out the files you have changed (or easier, the root folder), and then manually merge the two sets of sources. You can then "undo check out" to get rid of the unchanged files (say "no" to the "discard your changes" question and it'll keep locks only on changed files) and after testing that your code works, check in the resulting changed files.
You need another Workspace, that is a local folder were your working copy resides (Yes, you can have more than one).
With a fresh Workspace with no changes on it, you could recover your shelve there, do the check-in, and have your original workspace untouched. Optionally, you could delete the alternative Workspace, or keep it for these kind of maintenance tasks.
For creating a new Workspace, just open the Source Control Explorer and open the Workspace combo-box on the upper toolbar. Select Manage Workspaces and create a new one from there.