C# FileSystemWatcher does not catch a Perforce revert. It works fine when the same file is modified. This causes a problem because the revert changes the file, but FileSystemWatcher does not get notified.
How do you watch for a Perforce revert?
Thank you.
In addition to checking the NotifyFilters, make sure you're attaching handlers to all of the events that the FileSystemWatcher has. FileSystemWatcher has events for Changed, Created, Deleted and Renamed.
If you're only attaching to the Changed event and not catching any events, then it sounds like Perforce might be deleting and recreating the file. If this is the case, add handlers to the Deleted and Changed events.
The NotifyFilters documentation on msdn has example code showing handling for all of the events.
Have you set the NotifyFilters appropriately? From the FileSystemWatcher help...
There are several types of changes you can watch for in a directory or file. For example, you can watch for changes in Attributes, the LastWrite date and time, or the Size of files or directories. This is done by setting the NotifyFilter property to one of the NotifyFilters values.
A Perforce revert may also revert to the previous LastWrite time which, if you're only looking for a more recent timestamp, won't trigger an update.
I tried a sample executable from CodeProject, it seems to work, must be my code that's bad...
I suspect that Perforce report does a copy from a temporary file, so it's not actually writing to the file, but copying in a new file and blowing away the previous one. So since the file isn't being "written to", you don't get the notification. It doesn't help you though :(
Related
I had submitted a change-list containing some new files and then for some reason had to back-out.
Now I am trying to submit a new change-list that adds the same file back.
The problem is that when I backed-out, it deleted those files from HEAD revision and now when I am trying to submit my change-list it says 'Out of date files must be resolved or reverted'
I tried googling the solution but could not find anything relevant, can somebody please guide me right direction?
You just need to back out the first back-out. (When you say you backed out the addition, you mean you also submitted it, right?)
Locate the changelist that you submitted, e.g. via P4V's Submitted tab, right-click and choose Back Out....
It's best if the files you're trying to resurrect (re-add) don't already exist on your filesystem, otherwise Perforce will refuse to overwrite them. (Which may be what the error message is telling you; I'm not sure.)
I have created feature branch for one of our projects, and deleted all documentation files there in one changelist. (I know, bad idea).
I want to integrate back everything except given changelist, I tried following to ignore it:
p4 integrate //branch/...#CL,CL //main/...
p4 resolve -at //main/...
However, the files still remain marked for deletion - the resolve ends with
//main/... - no file(s) to resolver.
Is there any way how to tell perforce that given CL is already integrated and ignore it in subsequent integrations?
Note that you need at least a 2011.1 server to do this (if your server is older you'll get an error message on the integrate):
p4 integrate -Rd //branch/...#CL,CL //main/...
p4 resolve -ay
The "-Rd" flag says that files which would normally be opened for delete automatically should be opened for integrate and scheduled for resolve instead. In turn, the "p4 resolve -ay" will say that you want to keep what's in your workspace (an "integrate" with no content change) and submit that as the final result.
The submitted "integrate" revisions will record that you have done this integration (the history will show an "ignore" of the deleted revisions in your branch), but without actually changing the contents of the submitted files.
If you use the "p4 merge" command instead of the "p4 integrate" command (with a more current server version, I think 2013.1 or thereabouts), all files are scheduled for resolve automatically (i.e. including those that would previously have been automatically opened for branch or delete), so with "p4 merge" you always must resolve (and may optionally ignore) any source change.
Relevant p4 blog entries:
http://www.perforce.com/blog/110620/ignoring-branches-deletes
http://www.perforce.com/blog/130812/resolve-face-adversity
It seems like you wanted 'resolve -ay' here, not 'resolve -at'. When integrating back to main, I think that "theirs" is the branch, while "yours" is main.
From 'p4 help resolve':
The resolve process is a classic three-way merge. The participating
files are referred to as follows:
'yours' The target file open in the client workspace
'theirs' The source file in the depot
'base' The common ancestor; the highest revision of the
source file already accounted for in the target.
'merged' The merged result.
Filenames, filetypes, and text file content can be resolved by
accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
binary file content can be resolved by accepting either 'yours' or
'theirs'.
tl;dr: How to modify the .csproj file during publishing with ClickOnce while executing pre-build events?
Long:
I'm using TFS hosted by Microsoft for version control of my solution.
When publishing with ClickOnce, I get the latest revision number + 1 without problems. I also can successfully write the new version number into the .csproj file outside my build-process.
The problem is, that the .csproj file doesn't get updated during the build process - it might be in a write-lock. I get a notification inside Notepad++ about the modification of the file, but the file still contains the old version and VS didn't notice any changes.
The only solution by now I found to resolve this issue:
Move the revision update into the post-build events and add 2 instead of one to the actual revision number. Unfortunately this would cause that revision number would be out of date whenever other developers check-in code.
Ok, strike that... :(.
After some more diffing, you'll need to override the GenerateApplicationManifest target to get this to work. That target doesn't use a *DependsUpon propertygroup, so it's harder to overwrite. The whole flow is defined in the Microsoft.Common.Targets file which you can find in the %windir%\Microsoft.NET\Framework{cpu}\{version} folder.
See also:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3a94df52-74c1-4fca-a830-ab530ec49207/use-msbuild-to-create-clickonce-app-files-in-alternate-location
I have two branches _trunk and _dev.
There is a folder (actually it's config) where intensive work is performed in both branches.
Now I need to merge from _trunk to _dev. But I need to merge only the code.
The config should be REPLACED. I'm not sure that replacing it manually is right way. How this operation is called? How do you do similair things?
It's an integration as usual, but during resolve you'll accept the source files without trying to merge them into the destination. This will replace the destination files' content with the source content.
Edit: If there are adds and deletes in the source, make sure you let Perforce propagate those with the appropriate options checked.
You can do an "Integrate/Merge" from _trunk to _dev. Any conflicts will set up in your pending changelist as a "Resolve" for each file.
For code you can let P4V attempt to merge it for you and make changes / do the merge manually. For the config files, in the resolve window do "Accept Source" - this overrides the target with the source regardless.
Likewise, if there's any where you know you don't want to bring your changes forward but still want it to recognise you've checked and accomodated for the changes, use "Accept Target"
Maybe some Perforce gurus could provide some advice.
We have a depot, with a setting.xml file in central folder:
///depot/central/config/setting.xml
and would like it to be instanced in several locations, like:
///depot/projectA/tool1/config/setting.xml
///depot/customerB/tool2/config/setting.xml
The benefit is for maintenance. the setting.xml file only has to be updated once in //depot/central, then all files in the other places get updated as well, so we don't have to get into each place, duplicate it again and again.
AlienBrain has a feature called 'shortcuts', does Perforce have something similar?
We've tried use the OS' symbolic links feature, but it didn't behave the way expected -- cloned files still need to be checked-out first, then check them in again -- this makes the cloned files own their own revisions against the original one.
It's better to just keep the original and cloned files have the same revisions. so if submitting a new revision to setting.xml(5/5)(which makes it to be setting.xml(6/6)), the cloned files as this point still remains setting.xml(5/6). Thus, people on projectA & customerB can simply sync to the latest version.
Thanks.
You can use the Perforce client spec to map files from the depot into your workspaces, which should do almost exactly what you're looking for.
For example, your client spec for tool 1 would be something like:
//depot/projectA/tool1/... //workspace_for_tool1/...
//depot/central/config/setting.xml //workspace_for_tool1/config/setting.xml
And your client spec for tool 2 would be something like:
//depot/customerB/tool2/... //workspace_for_tool2/...
//depot/central/config/setting.xml //workspace_for_tool2/config/setting.xml
The main downside of this approach is that you need to make this change in every client spec, and you need some infrastructure dedicated to propagating client specs to new workspaces.