How to prepare for risky changes to a project?

Question

I'm about to try something risky on my scripture translation project. How can I protect it in case something goes wrong?

In Paratext trainings, I'm often told to "backup your project" before doing something risky. But I don't actually know the proper way to do that, and I haven't seen any articles about it.

In your answer, please speak to:

1. What is actually meant by "backup"? 
   1. Is this specifically making a copy of a project, or are there other things that I can or should do to be able to recover in case something goes wrong?

   2. Is it sufficient to use "Mark Point in Project History" instead?

2. What privileges are needed to take the steps necessary to make it (more easily) recoverable in the future?
3. What privileges are needed to recover the known-good state?
4. After I've made the risky change, how can I know whether something went wrong?

I would love to have instructions that I could give to any user involved in testing and training to follow so that they can use their real project data without worrying about messing up their project.

Update: Some of the testing I'm doing with users must include Send/Receive. Methods that require avoiding Send/Receive are not sufficient for all kinds of testing and training.

Answer 1

For what it sounds like you're about to do, copying the entire XYZ project folder out of your My Paratext Projects folder into another location is probably sufficient. Then, if something goes wrong, you can simply delete the project and then copy that folder back into its original place. That's by far the easiest way of "backing up", particularly in preparation for a one-time change that you're unsure of.

Rather that "Mark Point in Project History", I would recommend simply doing a Send/Receive. That process also marks a point, but has the advantage of being a slightly more robust backup--if you do something catastrophic to overwrite the history data on your local machine, that backup would still be in the cloud. This process is better than just copying the folder out like it suggested in my first paragraph, but it's also slightly more complicated to restore things. 

It is reassuring to know that it is extremely difficult to make a change that is so bad that someone can't restore an old copy of your project. I'd say it's almost impossible for you to corrupt data such an extreme, but not impossible for someone with access to the backup registry.

2 & 3

If you use the copy-folder method, you don't really need any privileges at all.

If you are trying to restore an old point in history, you may need administrator privileges (I can't remember off the top of my head). And if you made such a huge mistake that you can't fix it, you might need to ask for help from someone with access to the server.

4

That kind of depends on what change you made. But depending on what you're doing, you'll want to test this carefully before doing future editing on the project. It's extremely easy to delete a mistake and go back to a saved state a few hours ago. It's extremely difficult to realize after a month of work that some data is broken, but you've also made lots of correct changes in the meantime.

Comments

How does this advice change (or not) if the testing and training requires the use of Send/Receive? 

Some of the testing I'm doing with users must include Send/Receive. Methods that require avoiding Send/Receive are not sufficient for all kinds of testing and training. Sorry for just now saying this. I meant to include it in my original question and forgot.

Answer 2

Saludos Mercado.

Backup is a .zip file containing a copy of the project. It is a way to recover in case you do something that damages the files.

A history point is also useful. In case you want to go back to a certain point in the text or configuration, this history point will make it easier to locate the point prior to the changes. Occasionally, an error manipulating the project, especially if you directly manipulate the files, may require the .zip file to fix. 

One thing I recommend, in case you are trying something that you think will go wrong or is a major change is to make a copy of the project and do your tests there before proceeding in the real project (even if your tests go well in the copy project, don't neglect to backup the real project).

A user with Administrator permissions will be able to manipulate the history or restore the project. Only manipulate the files directly if you know what you are doing. In many cases, some project information comes from more than one file.

The backup is done from the Paratext Main Menu - Advanced - Backup project to file....

To create a copy project, create the project and then use restore to take the backup you took from the main project.

The restore option is in Paratext Main Menu - Advanced - Restored project from file...

Saludos,
Pepe.

Comments

How does this advice change (or not) if the testing and training requires the use of Send/Receive? 

I'm a designer for Paratext 10 Studio, and some of the testing I'm doing with users must include Send/Receive. Methods that require avoiding Send/Receive are not sufficient for all kinds of testing and training. Sorry for just now saying this. I meant to include it in my original question and forgot.

---

I understand.

When you take a backup of the real project and restore it as a test project you get all the information except for the history. So if your tests require the history this method is not convenient. Otherwise, if what you need is the text and the settings of the other tools this will be useful.

To take advantage of the send/receive you can create the test project as an auxiliary project related to the main one, so that you do not generate more projects that “confuse” the statistics. You can add to this project as many users as you need and the send/receive will work for all of them.

Now this is just one way to proceed, but as mentioned by friends in the other replies you can work on the real project having the right considerations and permissions. Take a look at Phil's answer, here below, for more information on how and who should proceed with this kind of testing.

Saludos,
Pepe.

Answer 3

Prior to making "risky" changes to a Paratext project there are some things that can be done to guard the data. Like insurance, it is hoped that you will not need this backup and can simply get rid of it after you are confident that your project is still working correctly.

1. Use Send/Receive to send the project to the Paratext servers. Make sure that all members of the project have done Send/Receive and then have them stop working until you have made the changes. This insures that the latest copy of data is on the servers for others to access. If there is a problem with your project, you can delete the project and download again. HOWEVER, if you have extra files (for example a \local folder or \PA7 folder), these are not saved to the server so you need to use another method.
2. The safest way to save a backup of the entire project is to simply copy the entire project folder to a safe location. This could be any folder on your computer. If you have a problem with the project, you can use this folder to get back to your data by simply copying the entire folder back to the c:\My Paratext 9 Projects folder. YOU MUST BE CAREFUL with restoring older data after doing Send/Receive as this can cause conflicts with the project. It is safe to restore the entire folder if no Send/Receive has been done to the servers with other data. If you have done Send/Receive and then you restore the folder on top of your data, you can cause conflicts.

• It is a Project Administrator who should make these "risky" changes (and recover from the changes). Everyone else should do Send/Receive and stop work until the changes have been made.
• The ability to determine if the changes were successful will depend on what the changes were. Generally, you can use the Project History (or Recent Changes) to compare the files before and after the changes. Unfortunately, this only applies to the text itself. Changes to other areas such as the Biblical Terms or Wordlist would need to be examined individually.

Step by Step

• Everyone on the team does Send/Receive and stops working during the change.
• Administrator copies the project folder to a safe location
• The Administrator makes whatever change is desired (see below if the change didn't work)
• The Administrator reviews the change to confirm that everything is okay and then does Send/Receive 
• The Team does Send/Receive and continues work

If the change didn't work:

• The Administrator can delete the existing project and do Send/Receive to recover the project from the server
• If there were special folders (like the local folder) then the Administrator can delete the existing folder and copy the backup folder into c:\My Paratext Projects 9
• At this point the Administrator could try again to make the change with corrections or continue to work
• Have the team continue to work.

Answer 4

1. "Backup" means using the Paratext backup feature (Project > Advanced > Backup project to file). In the vast majority of cases, it is sufficient to use Mark point in project history. Usually, the use of a backup is to create a new project separate from the main project to do testing with so you don't change any data on the main project.
2. Any user on the project with a non-observer role can create a backup or mark a point in history.
3. Only an admin can restore a state.
4. That is, unfortunately, up to you, the user, to figure out.

EDIT: Wow. Apparently this forum software doesn't update when someone else answers a question. Look at the other answers that were made while I was slowly typing my answer.