I have written a before-clientcheckin script to write the predicted changeset number into certain files on a user check-in operation. The script appears to be running successfully in that the new changeset number is being written to the target files and the check-in operation completes successfully.
BUT... unfortunately on check in completion a "Changed" copy of the file still shows up in the Pending Changes window. Bizarrely, this "changed" version of the file is identical to the one that was just checked in. I can get rid of it by undoing the change, which then makes my workspace and the repository equal again, with the correctly-versioned file still intact.
It seems that although the check-in is succeeding, the modification of the file by the script after the user commences the check-in operation is marking the file as changed again - even though its contents are actually unchanged.
Does anyone know how to avoid this scenario? There's no mention of this kind of issue in the Plastic Trigger manual, and although I have seen other posts from people trying to do something similar in a before-clientcheckin script, no one seems to have encountered this particular problem.
My Plastic version is 7.0.16.2421, running on Windows 10.
Any help would be much appreciated!
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'm facing an issue with TFS2012 where I have a gated check setup. Sometimes (not always) users are having files checked out by the build service (not a concrete type of files) with operations like add, delete and edit.
My first clue was something with the gated check in but accordingly to the information reconciles are being done, but the problem is that so far I can't trigger the issue, it just happens "sometimes".
I noticed that the build agent is doing the check outs, since if I go to the agent working folder I can find the files that have been checked out. It seems that the agent is reverting a change made by a user, but I still didn't fully understand it.
Do you have any idea what on the TFS could be causing this behavior, at least to give me some pointers on where to look for the issue.
I'm finding that a number of my changes are being 'lost' when our contractor performs a check-in.
The general process is as follows:
I perform some bug analysis and implement a fix.
I then check-in my code.
The contractor performs a check-out/check-in at a later date.
The changes from the previous changeset (my changes) are lost.
In my view, this is pretty unacceptable, particularly when I'm dealing with application-breaking regressions introduced since the last build.
This has happened at least twice now, and the only thing I can think of is that the contractor is failing to ensure that he has the latest changeset at check-out. Our repo does not allow multiple check-out, and forces get latest on checkout, which makes things so weird (seeing as we both should be working with Server workspaces).
Could there be any other cause of this problem? I don't want to take my concerns to my line manager without being sure I've covered all bases.
Get Latest item on check out is set in the client and not in the repo, which means that your contractor may still be able to checkout the wrong version. They should get merge conflicts upon doing so, but that depends on where they edit (and how they manage such conflicts).
I've seen TFS lose changes this way. I have yesterday gone to a client site, made changes, checked in, today come back to my office, got the changes (assuming it will merge with my local changes like it usually does), gone to check in just now and I can see in the diff that it's wiped out the client-site changes (obviously ignoring the merge locally). I checked in just to confirm what I was seeing and yes there was no resolve conflict needed, TFS thought everything was ok, but my modified local file just blatantly overwrote the modified version in TFS effectively discarding the whole client-site change (just like if I'd chosen resolve conflict keep mine - however it never asked me about the conflict or suggested that there was one, just silently lost it)
If you eye-ball the changes before committing you can see that the changes you are making are more than you thought - i.e. the client site changes are effectively being removed and will show as differences - however it's easy to miss this when you are doing it a lot.
I had previously thought to blame coworkers when they skip out my changes this way, but now I've actually seen myself do this to myself I realise the tool is deficient. Hard to believe but there is obviously something wrong with the way it merges your locally changed file against the 'get latest'. I'm using a cloud TFS with a flaky network connection sometimes - I'm told this contributes to the issue.
We've lost at least one changeset in TFS (we don't know yet if there's more, could be none). We noticed a changeset that was at the top of the list is now gone. We think there might be two at least because the symptoms below also exists for at least one other file we've discovered. Additionally, we can see a hole in the changeset numbering sequence, and we don't believe the changeset with the file described below is that one.
The single file involved had one line changed, and the version in TFS has the file before the change.
Doing a get latest or get specific version gives me the old file, before the change.
After doing the "Get specific version", in Source Explorer, in the column that shows workspace status, it says "No" indicating that the file is outdated. Nothing I've tried so far gives me the file with the change that was checked in.
If I try to view the file from the Source Explorer, it says my file is out of date and asks if I want to view the server version or the workspace version. Selecting the workspace version gives me the file before the change (probably because I did the get specific version above), selecting the server version gives me nothing, dialog just goes away.
If I check out the file, and redo the change, and try to check in, it says that a newer version exists on the server and asks me how to resolve. I can pick discard local changes or discard server changes. Since I want to check in my changes, I select to discard the server changes, but when I try to check in again (conflicts in TFS stops the checkin process), it just repeats the conflict and asks what to do.
Basically:
Changeset is gone, verified with the developer that checked it in
File does not have the change on the server
Server is confused regarding version of this file, complains about outdated version if I try to view it
Won't let me check in changes, just repeats a conflict with a newer version, presumably the file the developer checked in that for some reason is no longer available through a changeset
So... anyone had this problem? This is TFS 2008 with everything I know of updates applied, including all service packs on the developer machines, running Visual Studio 2008 Professional with Team Explorer 2008.
What do I do? Is my only recourse reverting to the nightly backup?
Edit: Things I'm trying after posting the question:
Checking disk space on server hosting the SQL Server (same as the TFS server): Plenty, 6GB free on one disk and 9GB free on another. Perhaps not plenty enough for the future, but easy to increase (virtual machines), but should not have anything to do with our current problem.
No change: Recreating a fresh workspace in a different folder on disk (I deleted them all before adding a new one), doing a "Get specific" version on root folder of project and checking the bottom two checkboxes (overwrite writeable and overwrite all), afterwards says that I have the latest file (Yes in that column I mentioned above). Viewing the file shows me file before the change. Doing a "Get specific" version on that particular file makes it turn to "No", same problem with checkin.
Solved??
I did another checkin on a totally different file, not including the file we had trouble with above, but that file was "attached" to that changeset, even though it was definitely not checked in by me when I tried this.
In other words, it looks like the part of the changeset that related to the file was still in TFS, with the right changeset id, so when another changeset appeared with the same id, that file became a part of it.
Has anyone experienced anything like this? It doesn't really improve my trust towards TFS if things like this can happen.
We still have another file that misbehaves, I will have to see if it has all of the same problems or not and what, if anything, we can do with that. If that file is related to the other changeset we seem to be missing, I don't think we can get that changeset into the database unless we fire up a SQL tool (which I'm really not going to do.)
Yesterday I worked on a set of changes I don't want to check in yet, and at the end of the day, decided to shelve my changes. The changes included a bunch of added files. The shelving worked fine, but today when I unshelved, the following happened:
VS told me four writable files already exist in my workspace. These files were the ones I added
I told VS it's all good, overwrite them and we're set
VS finished the unshelve...
... but left the "pending changes" tab empty.
I figured maybe something went wrong and re-tried the unshelve. At this point VS proceeded to tell me I've got pending changes in my workspace. So now I can't check in, can't unshelve and apparently the files are locked for edit under my name (yes, we use the lock-modify-unlock mode, unfortunately). What gives, and how do I fix it?
Edit: Upon further inspection, Source Control Explorer doesn't show pending changes from me, so apparently it's just my workspace that's borked. Correction: yes, it does, I was just looking at the wrong branch, aargh!
Edit 2: tf.exe does show the changes. I tried to undo them, delete the files that were still in the workspace (the ones that caused first VS error) and unshelved without errors. For a short while VS displayed the pending changes, but when the operation completed, they all disappeared.
OK, I'm just full of stupid today. The shelveset I was working with didn't belong to the branch I had open. Opening the project from the correct branch miraculously shows the changes in the pending changes tab!