I have create a pwa in project server 2010.
Then I create new project, defining tasks and assigning those tasks to resources.
I have set time reporting period so any resource must report her/his working time about any task assigned to her/him.
When a resource changes any field of his/her tasks (e.g. Finish Date, Remaining Work, %Work, ...) he/she Send status to PM for approval.
When PM rejects this page and publish project again, this change does not take effect in resource's timesheet. But since this changes rejected, one reasonably can expect that in the case of rejection, the changes come back to old.
Is anyone know how can resource bring out that fields to their old values?
Thanks for advance.
My answer is rather based on my knowledge of how MSP database looks like than on my experience in similar cases.
MSP does not store any kind of "transactional" data. You cannot do some changes in a project plan and later reject them and rollback all the changes to some previous state. Draft database stores current status of a project, Published database stores the last snapshot of the project created during publishing procedure. The only database which can store several versions of the same project is Archive.
So practically the only way to "rollback" some changes in a project is to put the project into Archive before somebody change it and restore it from the Archive when it was decided that the changes should be rejected.
Related
I want to create rollback task for Release Management in visual basic online.
i have some steps but it will take more time.
steps are:
Back Up: perform a backup of the original files to use for rollback later.
Deploy:Copy latest files from artifact to the target folder.
3.Configure — Make configuration changes to the setup.
4.Rollback — Rollback the files from backup in case Deploy failed. Delete backup before exiting.
we can see it will take long time while backup a database . So how we can optimize ?
is there any other method so we can implement and take less time when we will do rollback task ?
There isn’t the built-in feature/task to rollback changes in release, you need to do it by your own script.
There are various options that can be considered as a rollback
strategy.
Option#1 : Undo the change by redeploying the previous release
The first option is to simply redeploy the previously successful
release. This might work well for standalone applications.
Whenever an application depends on some external services or has a
database involved, this approach does not work well. The dependent
services might have upgraded and no longer compatible with the
previous release. The database might have changed the schema making
the previous release no longer healthy.
Option#2 : Fix the issue, do another release
The second option is to simply do nothing. Something went wrong,
troubleshoot it and fix it. Once we fix the issue, we can do another
release.
This however means the environment would remain unhealthy for some
time, as long as it takes for the fix to be ready and deployed.
Option#3 : Understand what failed in the deployment and make a temporary change for the time being
Both the above options are both valid approaches but with some
limitations.
That brings us to a third option. While the fix is getting ready
(option 2), make a minimum change to the environment to get it
temporarily healthy.
More information, please refer to: Implement Rollback with Release Management for TFS 2015 (Apply to VSTS)
You can't really optimise the backup/restore process.
If you use a Virtual Machene to deploy to then you should snapshot it prior to the upgrade, then a roll back is simply restoring the snapshot.
This will be much quicker, seconds, rather than minutes or hours...
We currently have an issue with our TFS server locking up whenever any of our developers attempt to check in a pending delete on a folder, however, this is a relatively new (within the last couple of months) issue, and we have been struggling to determine the root cause.
Essentially, the process that is occurring is something like this:
Create folder in TFS.
Branch from Dev trunk, creating the branch in the new folder.
Make any code changes in branch.
Merge changes from branch into Dev trunk.
Delete branch.
Realize we no longer need the folder.
Delete the folder.
Attempt to check-in folder deletion.
TFS server locks up, not allowing any operations to be performed until the server is restarted.
So, I am looking for two answers:
Why is TFS locking up when attempting to check in a folder deletion?
What can we do to resolve the issue?
A little bit more info:
This problem occurs for every user, including out TFS administrator(s).
It may occur even when there was never anything placed in the folder, but we haven't attempted that, so that we can avoid having to restart the server.
This has not always been an issue on the server, as it use to be relatively common for us to delete folders.
This issue occurs regardless of how the delete is being performed (VS2012, VS2015, command line, etc.).
We primarily work with a single trunk, but have potentially hundreds of branches being created over the course of a month.
The solution contains roughly 20-25,000 files, currently.
A remote CMIS repository contains many folders/files.
I am writing a software that keeps a local copy of these folders/files in sync.
At first run I just download everything recursively.
At later runs, I check what has changed, and download any changes.
What is the most efficient way to check the remote changes?
(additional/removal of files/folders)
Most efficient = Least bandwidth usage.
I can only use the CMIS protocol, and I can not run any custom software on the remote server.
My ideas so far:
Idea 1: Re-download everthing every time.
Idea 2: Check the root folder's modification date, hoping modification dates are recursive.
Idea 3: Use CMIS search to find all files that are more recent than the last time I synchronized. Problem: that won't tell me which files have been removed.
Any other ideas?
I don't know the CMIS protocol much, there might be something more convenient.
Using the repository's change log is the right way to go, but realize that not every repository supports this. For example, for Alfresco you must configure the audit sub-system and you must set audit.cmischangelog.enabled=true in alfresco-global.properties.
To find out if your repo supports changes you can look as the results of the repository's getCapabilities response. If you see 'Changes' set to 'None' then your repository doesn't support change logs.
Assuming it does, you need to ask the repository for its latest change log token. You can get that from getRepositoryInfo. Save that before you call getContentChanges. Then, on the next call, pass in the token. You'll get the changes made since the token was issued.
So, your code needs to:
Check getCapabilities for something other than Changes = None
Save the getRepositoryInfo's latestChangeLogToken
The first time you ask, call getContentChanges with no arguments
The next time you ask, call getcontentChanges with the last saved token
You can then process the result set. Each change log entry tells you its type (created, updated, deleted, permissions, etc., see spec for exact values) and provides the cmis:objectId of the changed object.
Repeat with step 2.
I have a "cmis-sync" script that does one-way synchronization using this approach implemented in Python. I've tested it against Alfresco as the source and the OpenCMIS InMemory repository as the target. If there is interest I can make it available.
A more ideal version of idea 3 is easily accomplished according to some digging through the CMIS protocol you posted.
2.1.11 Change Log
CMIS provides a “change log” mechanism to allow applications to easily discover the set of changes that have occurred to objects stored in the repository since a previous point in time. This change log can then be used by applications such as search services that maintain an external index of the repository to efficiently determine how to synchronize their index to the current state of the repository (rather than having to query for all objects currently in the repository).
Entries recorded in the change log are referred to below as “change events”.
Note that change events in the change log MUST be returned in ascending order from the time when the change event occurred.
Using whatever tools of your choice, you should be able to do an initial pull of the entire repository and save the time the pull was performed. Subsequent queries to the repository (at an interval of your choosing) are done with the following procedure:
Pull down the CMIS changelog from the repository
Parse all changes created after the previous pulls
Perform operations based on the ChangeType enum: for example, if the "deleted" enum is present for an objectID, delete that object locally.
I didn't get any overlay change when my teammates make changes or add a new file to my project.
Should I regularly update my project to keep track with the updates made? Or am I missing any configuration part that shows a new overlay whenever any of my teammates makes a change?
Note: I get red and other overlays correctly whenever I make changes to files.
Yes, you would need to do periodic updates to get changes from you team members. The trigger for this could also be one of the folloiwng.
A notification from the continuous integration when a build containing changes from other team members has been done.
A post-commit hook in your subversion server which emails all interested parties whenever there is a check-in.
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.