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.

Improve this question
17
  • 15
    @rwong - or a wiki with versioning, that could work too.
    – Joris Timmermans
    Dec 8, 2011 at 9:26
  • 4
    Adding to @MadKeithV comment, how about a git powered wiki? 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 8, 2011 at 9:34
  • 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 8, 2011 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 8, 2011 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 8, 2011 at 14:43

17 Answers 17

Reset to default
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.

Improve this answer
13
  • 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 8, 2011 at 15:24
  • 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 8, 2011 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 8, 2011 at 17:35
  • 7
    @user606723: TortoiseSVN and TortoiseGIT offer windows shell integration.
    – Roy Tinker
    Dec 8, 2011 at 22:20
  • 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, 2011 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.

Improve this answer
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 8, 2011 at 9: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 8, 2011 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 8, 2011 at 17:10
  • 4
    @DavidThornley: you haven't heard of actual security problems with Dropbox???
    – sam hocevar
    Dec 8, 2011 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 8, 2011 at 17:56
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.

Improve this answer
5
  • 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 8, 2011 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 8, 2011 at 12:19
  • Yay - downvote with no explanation, always like those.
    – Murph
    Dec 8, 2011 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 8, 2011 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 8, 2011 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.

Improve this answer
5
  • 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 8, 2011 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 8, 2011 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 8, 2011 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 8, 2011 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 8, 2011 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).

Improve this answer
1
  • Very promising, but maybe a bit immature. I will definitely keep an eye on this though.
    – Zsolt Török
    Dec 9, 2011 at 8: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

Improve this answer
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.

Improve this answer
5
  • 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 8, 2011 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 8, 2011 at 18:42
  • -1 because "automagically" is not a word.
    – dreftymac
    Dec 8, 2011 at 19:03
  • 4
    @dreftymac en.wikipedia.org/wiki/Hair-splitting
    – SplinterReality
    Dec 9, 2011 at 7: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, 2011 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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
3
  • 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 8, 2011 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 8, 2011 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 9, 2011 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.

Improve this answer
2
  • +1 as this is what our team is already doing, and it works.
    – sq33G
    Dec 8, 2011 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, 2011 at 8: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.

Improve this answer
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.

Improve this answer
1
  • +1 for pointing me to new commercial offering in the DVCS realm
    – Roland Tepp
    Dec 14, 2011 at 18:58
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.

Improve this answer
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!

Improve this answer
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.

Improve this answer
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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.