57

We're teaming up with some non programmers (writers) who need to contribute to one of our projects.

Now they just don't like the idea of using Git (or anything for that matter) for version controlling their work. I think this is because they just don't find it worthwhile to wrap their heads around the twisted concepts of version control. (when I first introduced them to branching and merging -- they looked like I was offending them.)

Now, we're not in a position to educate them or convince them to use it. We're just trying to find alternatives so that we get all their work versioned (which is what we need) -- and they get easy workflow and concentrate on what they do.

I have come up with some ideas...

  • tell them to save their work as a separate file every time they make some non-trivial change, and then use a diff on our side to just track changes.
  • write a program (in Python) that implements the "milestones" in CSSEdit in some way.

About the project:

It is a natural language processing system (written in C + Python). We've hired some writers to prepare inputs for the system in different languages. And as we evolve the software, we'd need those writers to make changes to their inputs (articles). Sometimes the changes are very small (a word or two), and other times big.

The reason we need to version control those changes is because every small/big change in the input has the potential to change the system's output dramatically.

durron597
  • 7,590
  • 9
  • 37
  • 67
treecoder
  • 9,475
  • 10
  • 47
  • 84
  • 1
    Will a daily desktop backup program work? How about a daily email of the work files? – rwong Dec 08 '11 at 09:11
  • 1
    Yes something like that might work. But we need something better than that because we need to be able to refer to a version, and ask them to change it. This means that they should also be able to browse and manipulate the history. Also, we'd like the system to integrate with our own workflow in some way. – treecoder Dec 08 '11 at 09:15
  • 2
    Things come to mind: a document management system, a content-management system, or ... a blog! (articles arranged by date) The most important point is that it's web-based, that's all we care. – rwong Dec 08 '11 at 09:23
  • 15
    @rwong - or a wiki with versioning, that could work too. – Joris Timmermans Dec 08 '11 at 09:26
  • 1
    Yes that is one option, and it's good -- but it still requires the writers to changes their workflow. We'd rather like to just augment their existing practices and tools -- because these writers just reprehend our any attempt to disturb their workflow :( – treecoder Dec 08 '11 at 09:30
  • 4
    Adding to @MadKeithV comment, how about a git powered wiki? https://github.com/github/gollum - Some changes to the workflow are going to be made, you are trying to bridge two teams. Have you explored their current tools? There's a small possibility they support some kind of version control and your writers never bothered to find out.. – yannis Dec 08 '11 at 09:34
  • 1
    They'll be using simple text editor because we need a clean UTF-8 text as input. Indeed they don't have any workflow of sorts, it's just that they are too stubborn to learning anything new. A wiki is indeed the best option, but I was looking for any ideas for something even easier -- if any? – treecoder Dec 08 '11 at 09:42
  • 1
    They may not have encountered version control before, but it is simple enough, and has clear benefits for any kind of document. I suggest you try harder to explain what & why you want to use it. Or hire smarter writers. – NWS Dec 08 '11 at 10:16
  • 20
    Its really simply. If you are going to pay these people, tell them they can either use your tools and get paid, or if they refuse to use your tools don't get paid. Any middle ground will mean more work on your end, since that costs money, it balances out to finding a group of people who will work with your tools. – Ramhound Dec 08 '11 at 14:08
  • 4
    Fossil is an interesting VCS that comes with a versioned Wiki as well. We used it as a way to keep docs up to date but you could use it to "version" things like this. – Ben Brocka Dec 08 '11 at 14:36
  • 34
    WHY were you trying to introduce branches and merging to non-techies? You want their work versioned, fine. You can tell them how you want it saved. You want them to handle branches and merges, you're going off the deep end. You should have gotten them something nice and easy, like Tortoise*, and avoided telling them anything they really didn't need. – David Thornley Dec 08 '11 at 14:43
  • 1
    @Ramhound: that kind of attitude doesn't work very well with top-shelf people. – whatsisname Dec 08 '11 at 19:39
  • 3
    @whatsisname That kind of attitude doesn't bother the truly top-shelf people, only the ones who (erroneously) consider themselves to be top-shelf. – dash-tom-bang Dec 08 '11 at 19:55
  • 1
    @whatsisname - The fact a contractor is telling their client they are not willing to use a tool is a problem. The fact this is not happening tells me they are not "top-shelf people" more like "rusty bottom shelf" people in my book. – Ramhound Dec 08 '11 at 20:39
  • 1
    What software do they write documents in? Chances are that there is a plugin to integrate with your versioning software already. – JuniorDeveloper1208 Dec 08 '11 at 19:40
  • @Ramhound except that contractors should have enough professionalism to decline contracts where they do not believe they will be productive. Choice of tools has a great effect on productivity, so it's perfectly reasonable sometimes for contractors to refuse a project where they have to work with certain tools. (But in this case, I don't see why the writers couldn't at least give the tools a try.) – Marnen Laibow-Koser May 15 '18 at 16:23
  • I tried Fossil, but had a bad experience with it. Something got corrupted, and the problem was either in the Registry, or some hidden directory, or something like that. Deleting the directory completely and reinstalling wouldn't work! Never figured out how to resolve the problem. – MicroservicesOnDDD Mar 11 '20 at 19:46

17 Answers17

102

when I first introduced them to branching and merging -- they looked like I was offending them

This is probably because branching and merging are advanced concepts, and infinitely less useful than to simply keep track of the changes.

So why not explain just "commit" (save) and "update"? Two really simple concepts. I'm sure you can explain it in less than 10 minutes.

If you really want to use separate branches and stuff like that, you can do that part yourself without involving them with it.

Andreas Bonini
  • 1,073
  • 1
  • 9
  • 16
  • 20
    +1. For their purposes, just keeping straight-line history is a radical and game-changing notion. I think it's unlikely a writer would ever really need branching and merging, and if they did, they'd need a dev's hand to hold while they managed it. – Dan Ray Dec 08 '11 at 15:24
  • 2
    +50, I've been programming for 20 years and have been able to avoid branching and merging, if someone tried to force it on me I'd be offended! (git does kind of force more dealing with that crap, but with SVN you're fine--even if you have to use locking to ensure there won't be any merges, it'll work great). – Bill K Dec 08 '11 at 16:28
  • 7
    @BillK, have you actually tried merging with git? I think it works quite well, much better than with SVN. (I'm not advocating using merging where it's not needed, though.) – svick Dec 08 '11 at 17:31
  • 10
    @Bill K Honestly, this sounds like you need to do some catching up after 20 years on SVN (if even). Branching and merging might really not make sense for these writers, but I'm not sure how you managed to program for 20 years without ever branching a repo. There are so many cases where branches are good practice and ease your life; in fact, blindly rejecting the concept shows poor judgement (IMHO). In SVN branching was a pain, but with git things got really easy. Do yourself a favor, get over your ego and invest an afternoon to learn git's basics. You won't regret it, promised! – Robin Dec 08 '11 at 17:35
  • +1 We have our "writers" (Tech comm) using starteam just fine. Now, starteam has a graphical interface, which makes this a bit easier... But I would be hard pressed to think that you couldn't find an SVN or git graphical interface somewhere. – user606723 Dec 08 '11 at 17:45
  • 2
    +1 I was indeed wrong. I tried to explain them Version control hoping that it would be an enlightenment to them (as it was to me), but I ended up upsetting them. – treecoder Dec 08 '11 at 18:09
  • 1
    @greengit The challenge in working with people is that you need to present information to them that is relevant to them. People don't tend to want information that is irrelevant to them, so this may be as much why you had looks of horror from them as anything. – dash-tom-bang Dec 08 '11 at 19:57
  • @Greengit - Your first mistake was trying to teach people you plan on giving a check to something. All they need to know is how you want something to be given to you, you could in theory have them print out each copy, and keep track of the "versions" and provided your company was willing to pay to do that they should do it. – Ramhound Dec 08 '11 at 20:42
  • 2
    @Robin I've done merging before and yes, merging is easier with git--but no, I do not want to merge. I am very poor at guessing what an other guy was trying to do, so most of the time I go for really quick check-in cycles and if a merge is not immediately obvious (or resolved by the system), I revert to his version and re-add my few changes. Personally I'm happier with locking, but I recognize that very few people are as handicapped as I am when it comes to guessing (I ALWAYS guess wrong, it's like an inverse super-power)--so I work around the problem without trying to change others – Bill K Dec 08 '11 at 21:40
  • 7
    @user606723: TortoiseSVN and TortoiseGIT offer windows shell integration. – Roy Tinker Dec 08 '11 at 22:20
  • You could even write a simple little graphical utility for them to use that abstracts the idea of commit and merge into something more familiar. And does that only. – Kim Burgess Dec 09 '11 at 01:34
  • 2
    They don't need to know anything about branching and merging. Communicate with them in language that ***they*** understand. They aren't programmers, they are writers. Git is easy to use, if all you are doing is committing and pushing. – B Seven Dec 12 '11 at 23:33
  • 6
    I'm pretty sure that trying to teach Git branching and merging to non-techies is a violation of human rights. – Steve Bennett Dec 13 '11 at 20:41
70

A rather unorthodox approach would be just use Dropbox. Have the authors save the files in the dropbox directory and you get versioning and backup for free. Plus there is basically no learning curve for the authors.

For git, sounds like in the end you gonna end up providing the authors with the correct branch versions anyway, so just put the git repo in the dropbox and handle the branching and merging for the authors.

OliverS
  • 1,285
  • 1
  • 10
  • 11
  • 22
    I was going to suggest the same thing. No reason why you can't also make the folder in Dropbox a git repo (they don't need to know) and do periodic (e.g. daily) commits. That way you get all the nice git stuff (diffs, logs, bisects, etc) for free. – Simon Whitaker Dec 08 '11 at 09:55
  • 5
    Make sure you use the paid version, as the free version only saves versions for ~30 days if I remember correctly. – DMan Dec 08 '11 at 15:16
  • 5
    I can only -1 an answer that suggests an external service, introduces a single point of failure, and puts your data at the mercy of potential intruders, when there is so much useful software suggested in other answers here and the involved parties are explicitly presented as capable programmers. – sam hocevar Dec 08 '11 at 17:10
  • 2
    @Sam Hocevar: I don't see the problem in introducing an external service. It's a fixable point of failure, as if Dropbox goes out of business you've still got copies around. I don't know how sensitive the writing will be, but I haven't heard of actual security problems with Dropbox, and so it may be secure enough. – David Thornley Dec 08 '11 at 17:42
  • 4
    @DavidThornley: you haven't heard of [actual security problems with Dropbox](http://news.cnet.com/8301-31921_3-20072755-281/dropbox-confirms-security-glitch-no-password-required/)??? – sam hocevar Dec 08 '11 at 17:51
  • 3
    @Sam Hocevar: OK, now I have. That was four hours of vulnerability, which sure isn't good, but doesn't necessarily mean it's a bad idea. Again, it depends on how sensitive the writing is, and if a small chance that it could be seen by an outsider is acceptable. (It's obviously unfit for medical records, but I have no qualms about leaving bad fiction and unfinished software projects there.) – David Thornley Dec 08 '11 at 17:56
  • 3
    +1 to @SamHoceva. This is a terrible idea. DropBox is not meant to be used like this. This might be fine personal solution for near the same thing, but not for corporate use. – user606723 Dec 08 '11 at 18:19
  • @SamHocevar no single solution is perfect. This might be a usable solution here and now. –  Dec 08 '11 at 18:33
  • 3
    @user606723: Not all personal and not all corporate projects are alike in security requirements. Dropbox (and I'd lump all cloud storage providers in here) is not suited for high security data, but it will do nicely for low security. Since we don't know what's being produced, we can suggest Dropbox if the documents in question don't need high security. – David Thornley Dec 08 '11 at 21:02
  • Ok, sure, but what happens if you happen to need to version something with higher security? You have to implement and teach a whole new system. – user606723 Dec 09 '11 at 02:33
  • 1
    @user606723 Why do anything? You might have to change things in the future! WHAT YOU ARE DOING NOW IS A WASTE OF TIME!!! ZOMG! Seriously tho... I doubt these writers need to follow "extreme" security measures, so I'd bet money this would be a perfect solution. Anything online is at Risk. The question is, would this meet TODAYS requirements? And would the risks fall within the accepted range. – WernerCD Dec 09 '11 at 19:06
29

Truthfully the answer is in your edit: "We've hired some writers" - sometimes you just have to be bloody minded... they want your money they have to do what you want providing that what you want is not unreasonable.

The argument you make is the argument you've already advanced - we need to be able to do X, Y and Z to make the product work - and in order to do this we need you to do that. We will be as supportive as we can, but for this to work (and therefore for it to continue as an income stream for you, the writer) this has to happen.

I tend to agree that an appropriate Wiki based solution would seem to be a good match - but the challenge here is how to find a compromise between their workflow and your requirements.

I'll repeat the key point - in order for your project to be a success you need the articles to be versioned therefore those who work on the articles have to play by an agreed set of rules, if this doesn't happen you will get burned and by extension so will the writeres.

Murph
  • 7,813
  • 1
  • 28
  • 41
  • 1
    I totally agree with you. But you see there is something called "management" between us (the team of programmers) and the writers. Management hired the writers, and told us to work with them. The fact that they're reluctant to learning Version control is something that management sees as an issue needs to be "adjusted" between us (the team) and them (programmers). – treecoder Dec 08 '11 at 12:09
  • 2
    I kind of guessed... but then you have to make your case to management, and its the same case. They're right that its something that needs to be "adjusted" (interesting choice of word) - but compromise is a two way thing, you have to give them something they can work with, they have to work with it. – Murph Dec 08 '11 at 12:19
  • Yay - downvote with no explanation, always like those. – Murph Dec 08 '11 at 13:48
  • 2
    @greengit Issues that need to be "adjusted" between teams are part of what management is for. Delegating the responsibility to one team is either lazy, or possibly a hint that management would prefer that team's approach. So I'd suggest you suggest to management the solution that makes more sense to you, and let them worry about everything else. – yannis Dec 08 '11 at 14:12
  • 3
    I have a tendency to present these "adjustments" to management in the form of the budget for their proposed changes. "Sure, we can avoid their using (git,…). We'll need to hire a secretary to do it for them. Sign here and I'll start interviews on Monday." – BRPocock Dec 08 '11 at 17:58
19

I've had to deal with a similar situation like this before. In the end we just designated one developer (me) as the version control point of contact for the 3rd party.

The 3rd party would email me a zip file of their project files every day and I would do the checkin for them. I setup a separate project workspace and svn account for them and would unzip the files into that workspace overwriting what was there and then do the checkin under that account.

It's wasn't the most fun to have to do every day but sometimes it's more important to just get the work done.

One plus was that it did help me review their work to make sure they were not checking in bad code and data that would break the build.

Alan Barber
  • 896
  • 6
  • 12
  • 1
    +1 If that was possible, it'd be "problem solved!" for us. It isn't because we're small company and I don't think suggesting sparing one developer partly or solely for this task would return any smiles to me from (idiotic) management. Really, I feel about our management that way. – treecoder Dec 08 '11 at 13:55
  • 2
    @greengit - If you suggest this is the only solution you feel would work, then the costs will force mangement to hire different people, who will work with your tools. Of course you can explain to mangement that ANY solution except version control WILL COST MONEY either you working around problems ( and solving them ) created by the work around or spending the extra time trying to prevent the problems ( unless you ignore both of those key points, problems will happen, actually they will happen no matter what ). – Ramhound Dec 08 '11 at 14:11
  • 3
    @greengit Obviously it's going to depend on what's all involved in your process but in my case it took me less than 5 minutes a day to checkin the 3rd party files. It was my solution to mitagate wasting time trying to develop a process and train the 3rd party on it. – Alan Barber Dec 08 '11 at 15:12
  • It shouldn't be that hard. One person is the interface from the writers to the version control system. They know to submit all their changes to him. Shouldn't take him more than a minute or two to drop their changes in place and commit them. – Dan Ray Dec 08 '11 at 15:22
  • 1
    @greengit - This was going to be my answer. Yeah, it would take time away from doing useful work. Writing a custom system (which you seem to be eager to do) would take **more** time. And the writers would still complain. – Mike Baranczak Dec 08 '11 at 16:15
18

SparkleShare is a git-based dropbox-clone, I think it suits your needs.

SparkleShare creates a special folder on your computer. You can add remotely hosted folders (or "projects") to this folder. These projects will be automatically kept in sync with both the host and all of your peers when someone adds, removes or edits a file.

...here's a few examples of what it does well and less well with smiley faces:

Great

  • Frequently changing project files, like text, office documents, and images
  • Tracking and syncing files edited by multiple people
  • Reverting a file to any point in its history
  • Preventing spying on your files on the server using encryption

Not so great

  • Full computer backups
  • Storing your photo or music collection
  • Large binary files that change often, like video editing projects...

Update (November 2015): The project seems to be abandoned (last release from April 2014).

Tamás Szelei
  • 7,737
  • 7
  • 38
  • 42
13

If you can provide prepared workspace with transparent VCS-usage, they will use VCS. Don't teach non-programmers to use VCS in programmer's way

Just find editor with embedded VCS-support, configure it and show additional easy steps in their works.

Just an example - Editplus knows about Subversion, have ability to perform basic SVN operation inside editor window. Latest Editplus even can use TortoiseGIT for Git-integration

Edit: found some-way-alternative solution: EasySVN, which, being properly configured, monitor working copy and perform autocommit and automerge, allowing to use any authoring tool for end-user and any document's formats

Lazy Badger
  • 1,935
  • 12
  • 16
11

What about setting up a WebDAV?

It will automagically handle the straight line versioning history for them. All they have to do is connect to the server as if it was a network drive and every save will be a commit.

Malfist
  • 3,641
  • 5
  • 29
  • 40
  • 1
    +1 for WebDAV. Really didn't think about that option. How difficult do you think it will be to deploy and maintain a WebDAV server (+ workflow) – treecoder Dec 08 '11 at 18:31
  • 1
    It's really simple, you setup apache, subversion, a repo. Then you install the apache module and configure it and you're all done. – Malfist Dec 08 '11 at 18:42
  • -1 because "automagically" is not a word. – dreftymac Dec 08 '11 at 19:03
  • 4
    @dreftymac http://en.wikipedia.org/wiki/Hair-splitting – SplinterReality Dec 09 '11 at 07:25
  • 2
    Maybe, you can make this answer more explicit: Set up Subversion+Apache+WebDAV on a server and mount the WebDAV share from the non-developers clients. Tell the users to save they work on the WebDAV share at least once a day. – Jan Dec 10 '11 at 23:57
7

Google Docs

Google Docs might do what you want. File > See Revision History will let you keep track of changes.

You've also got the problem of handing files back and forth taken care of for free; just share the document amongst everyone.

Finally, it's easy to use; the writers don't even have to know that there is versioning happening.

Nathan Long
  • 3,667
  • 3
  • 24
  • 28
6

OS Agnostic

Write a Python program that you can drag and drop a file onto, that program can then do the git add and git commit and what not and they never have to deal with it.

or

Use a WebDav based filesystem you can mount on their machine and have the server do the git stuff transparently.

OSX/Linux

Write a Python based FUSE plugin that takes the files and commits them to git. Then they can just open and save from the mounted filesystem transparently. There are some FUSE for Windows resources, but they are probably not even worth fooling with.

Windows

You might could write some code to use FileSystem Filter Drivers to transparently do the git stuff.

5

Ah, the joys of non coders mucking about. I'd suggest getting a git/mercurial environment set up for them. Tell them to save everything in a format that the repo can handle. With tortoisegit or tortoisehg, they don't need to know how the repo works. They just check if they have an exclamation point in their project directory, right click the offending file, and click commit. Type up a synopsis of changes(they're writers, right?) and you are done!

An extra step in the work flow for them, but nothing about merging/branching/cool stuff. The pre built environment is already set up to be in the writers branch, so they don't see code. Have a script auto sync them every day. Later, after they are used to committing, you can show them extra features. The ability to see what changed when is so useful that they won't be able to do without it, once you sneak it into their workflow.

Spencer Rathbun
  • 3,576
  • 1
  • 21
  • 28
  • 5
    One thing I have come to realize is that **all** (YMMV) non-technical writers just consider their *previous* work useless, once they make any changes to it. They think the updated work (article or anything that they write) is best, and it's foolish to keep the past versions of it. Although in our case, we've at least successfully explained them why we also need the history also. – treecoder Dec 08 '11 at 14:29
  • @greengit perhaps. If you demonstrate how you're accommodating them to management, how this simple and easy step helps you, and how this saves/makes the company money, then they'll have to do it anyway. Business is driven by the bottom line, so tell the boss that this integrates the writers into the technical pipeline and saves money on integration costs, backups(you are backing up the repo, right?), and information passing. – Spencer Rathbun Dec 08 '11 at 14:49
  • +1 We have also set up our project coordinators and customer service people to use TortoiseSVN. After the initial explanation (and helping them with the inital checkout), they had no problem commiting their changed versions (mostly office documents and images of mockups). They even liked that they'd automatically get the latest version if a colleague changed something. – sleske Dec 09 '11 at 10:24
3

What about Share Point? I know it isn't popular in the development worlds but if your writers are using Windows as an OS it will work well and they won't really know that they are using version control(A big plus for my work).

This solution also keeps them from dealing with anything that would scare them to much, as it seems they are skittish of new things.

JustinDoesWork
  • 849
  • 4
  • 12
  • +1 as this is what our team is already doing, and it works. – sq33G Dec 08 '11 at 17:25
  • I prefer working with a proper version control system to SharePoint, where some of our company's documentation is, because uploading new versions to SharePoint takes more work. – Chris Morgan Dec 11 '11 at 08:34
2

Could you setup a tool that monitors the file system where the writers are saving their files and have it do an automatic commit every time they make a save?

If you put it on a network share you could do all the configuration without involving them at all; but every time they provided an updated version for your team to use it would be added to git for you.

Dan Is Fiddling By Firelight
  • 1,222
  • 1
  • 13
  • 16
1

Did you look at Plastic SCM. They are trying to make it simpler to use

If you just want versioned backups you can use Dropbox or you can setup Windows backup service. Or you can install Crashplan or another similar product.

Amala
  • 243
  • 1
  • 2
  • 7
1

For the Mercurial DVCS, there is a user interface called EasyMercurial, whose stated goal is explicitly to provide a simple view of the basic version control operations.

EasyMercurial is intended to be:

  • simple to teach and to learn indicative of the actual repository state, using a history graph representation
    • recognisably close to normal command-line workflow for Mercurial consistent across platforms

We are not trying to produce "the best" Mercurial client for any one purpose. We actively encourage users to move on to other clients as their needs evolve. The aim is simply to provide something accessible for beginners in small project groups working with a shared remote repository.

I would recommend giving it a try.

Laurens Holst
  • 101
  • 2
1

I've had to work with non-programmers many times (mostly graphic artists, and if your writers have as little clue how to manage work files as artists then you are in for... h'mmm.... fun...). There are three possible approaches:

  1. Pretend they are programmers, try to teach them how to use version control. This will not work and you will have constant fights.
  2. Write them a very simple tool which just grabs the current version & sticks it somewhere so they can rewind to yesterday's files if necessary. This is possible, and I did this for a team of DVD creators (making menus, graphics, all sorts of things) many years ago with some success: the tool I wrote was a one-click wrapper to PkZip (you can see this was a while ago) and it just zipped up the work directory and named the archive for the date + time.
  3. Take control of what they produce yourself. Make it clear that their files have to be delivered to a programmer and only become part of the project when the programmer accepts the files: the programmer then checks them into version control and the content is managed in a professional way.

Personally I think option 3 is the way to go. It means some pain & irritation for whoever has to take the file deliveries and get them checked in, but way less than any other option.

I would also say, be aware that non-programmers will deliver files with any old filename you can think of. Naming conventions are strangely alien to them. They will give you a file called "Picture" or something and then when you tell them the things that are wrong with it will give you a file called "Picture_Final", which has only correct about 3 of the faults. When you point this out you will get another file, called "Picture_NewFinal", and then (if you are lucky) "Picture_NewFinal2", although it is possible that they will at this point jettison any sense of historical development and call it "Spanner Icon thing".

Again you can try to enforce a naming convention, which means telling them in advance what every file is to be called, or you can spend hours unscrambling & renaming what they send you. Here I would say you want the spreadsheet for your own sanity anyway, so have a go at getting them to follow it: just don't be surprised when they don't.

Hope that helps -- have fun!

AAT
  • 101
  • 3
0

If there is any chance that two of them need to work on the same target at once AND if you can deal with all their work in text files, I'd try shared google docs.

It has awesome multi-editor/collaboration ability--by far the best I've ever seen. They are also full versioned and can be exported as text files.

But those are two pretty big ifs.

Bill K
  • 2,699
  • 18
  • 18
0

Let them work in a folder, saving files as usual.

Once a day (or week, etc) copy the contents of that folder to backup_dd_mm_yyyy Most systems source code occupies a trivial amount of space given the space available these days.

The copy can either be done by you, them, a third party, a tool or a script.

This limits loss to one day, gives a history, is transparent to them.

Not perfect for either party but an answer that seeks to strike a middle ground.

Michael Durrant
  • 13,101
  • 5
  • 34
  • 60