Git for the masses | Hacker News Reader

Git for the masses

kivo.com

114 pointszefi59 comments

Office already has features to track and merge different copies of documents together. Assuming you haven't disabled it, it also has (hidden) builtin versioning, allowing a git-like three-way merge with all the accuracy improvements that entails.

The larger problem is, of course, discovering that these features exist and training people to use them.

We're trying to make performing these actions simpler than they currently are. Would love any feedback or ideas.

I don't think those diffs are centrally managed though, which is a big problem.

Office used to have a rather handy (well-hidden) builtin versioning feature whereby new saves were not permanent. Instead only what changed was saved in a delta-fashion and so one could go back and access the different versions of a file (from different times) all in the same file.

This feature was good for the case of a solo author who working on a draft document and needing to keep various versions of the documents in one file (as opposed to having multiple versions with potentially funny names depending on the naming-scheme in use). Unfortunately, MS removed this feature way back when Office 2007[1] was released. OS-level file versioning functionality that exists can help fill the void though.

[1] - http://office.microsoft.com/en-us/word-help/what-happened-to...

One problem with the office track changes feature is that ALL PREVIOUS VERSIONS OF THE DOCUMENT ARE INSIDE THE DOCUMENT.

This is wrong, the document should be inside the VCS.

Some examples that my mother brought up regarding Law firms and the track changes feature are that if somebody writes 'adding this paragraph because of idiot customer X' or repurposes a document for customer Y into a document for customer X then some bright beaver at customer X turns on the track changes feature...

I'm sure there is a way to scrub the changes from the document before sending it but not separating the content from the history will always create problems.

Tracked changes show up in bright red, blue, and green colors. Difficult to miss, as long as you don't hide them. There are also ways to ensure that a "final" revision of a document is saved.

The hidden versioning I talked about are attributes on elements in the XML version of documents that are not normally displayed. They contain a random number that distinguish text edited in different "blocks" from each other -- making it possible to determine how to combine different versions of text, without containing full version history (and thus leaking information like in your example). It's not as good as a recursive three-way merge that git has, but it's reasonably effective when combining documents.

You are right that it doesn't separate the content from the history -- but keeping full history and keeping things private are at odds with each other anyway. Consider the outrage when people rediscovered the Fast Save feature -- it was very useful, but it also leaked potentially sensitive information in a way people didn't expect.

http://support.microsoft.com/kb/197978

http://news.cnet.com/8301-10784_3-9780073-7.html

Yeah, "Track Changes" and that feature that lets people put initialed notes in the margins of Word docs are pretty widely used among Word power users (it's how my wife and her supervisor are editing her thesis - my supervisor and I used a git-versioned LaTeX document with a custom macro for notes, but that's the difference between a humanities and a CS degree :-) )

I've been effective with Markdown and pandoc backed by git or Dropbox for my own work, but with shared documents it's always Word with track changes. I think part of the problem is that everyone you're working with needs to be comfortable with the editing tools you use, and with more people Word quickly becomes the lowest common denominator for collaboration.

> Office already has features to track and merge different copies of documents together

Only for MS Word I'm afraid.. :( (unless you want to buy a sharepoint deployment for the other products, and that versioning stuff is REALLY clunky!)

Excel has track changes, and Powerpoint can merge two different versions of a slideshow together. Word can do both, of course.

Yes, it's slightly clunky, but quite effective as long as you know how to use it: for example, you usually want to minimize unnecessary changes to formatting to make it easier to see differences, just like how you're not supposed to mix whitespace and code changes in a patch.

An often ignored aspect of version control is that commit access is strictly defined and enforced by the software. This is difficult when you have multiple versions of documents with formatting problems emailed around.

Kivo looks a lot like DocVerse. Which was eventually bought by Google and became Google Cloud Connect[1].

Google Cloud Connect was supposedly replaced with Google Drive[2]. No idea if it offers the same functionality. There may be 100,000s of people missing Google Cloud Connect which just isn't enough of a market for Google to pursue.

Personally, I don't think the problem is lack of tools or a better way than email. It's just lack of training or willingness to do something different.

[1]http://googledocs.blogspot.com/2011/02/google-cloud-connect-... [2]http://support.google.com/a/bin/answer.py?hl=en&answer=30170...

You're right, ease of adoption is the no. 1 barrier to products like ours and docverse. We know that to make this work, it needs to be at most two or three steps to be fully set up and working with someone else, and then very little effort from then on. No one has made it this simple yet. Also, we're doing slide by slide version control, rather than snapshots of the whole document.

People emailed themselves files before dropbox, but since dropbox I've never done that. That's the kind of ux needed to make any product solving this problem succeed.

If you try to use Google Cloud Connect you'll find that it's too buggy to use for more than 15 minutes.

I see this problem all the time in our marketing department. I think Microsoft Office is the problem, and the solution is to move toward systems which support collaborative document editing like wikis.

One of my pet peeves is emailed Word documents that the author has no intention that the reader will print. I prefer to read most documents in a web browser. I consider Word documents (and PDFs) to be skeuomorphs from a time when the printed page was the only means to share information: http://baus.net/documents-are-skeuomorphic/

Word is convenient for the author, but not the reader. I suspect over time its use will diminish as better collaborative systems become the norm.

Re: enterprise vc, I am still horrified whenever I think about the "diff tool" one of our top consultants from Big Blue used when coding in Java: copy code from IDE into Word, copy the Word file across systems, reverse the process...

As for what you guys are doing, it's fantastic and it was high time someone decided to tackle the problem. Another huge market opportunity is an editor tailored for writers (academia, fiction, etc), with vc embedded and an open format behind the scenes (HTML maybe).

hey ludoo - cheers for the reply; my name is Leo and I'm CTO @ kivo. Re for a version for writers, would this entail MS Word? We are planning to ship our Word version in the near future and it would be great to get your feedback on what you would like this to look like (leo@kivo.com). All Office files post-2007 actually do have the open format of OpenXML behind them, so we can totally see this being a reality.

This is the sort of problem that if you don't solve it very carefully, you will get a "working" monstrosity that you will wish was never created in the first place.

See: Sharepoint. I honestly prefer emailing around files, but good luck going back to that once you've got sharepoint.

completely agree, we'd love your help. I'm on zefi@kivo.com

Installing a plugin and pressing "Sync" may indeed be improvement over manually merging Word docs, although they do gloss over the hairy yet important bit of managing permissions: who exactly gets access to each doc?

But having gotten used to Google Docs, it's considerably more convenient -- hell, nearly magical -- to be able to just work and have your changes sync in real-time. For example, meeting minutes pretty much write themselves when everybody has the ability to edit the doc simultaneously and summarize what they've just said.

If someone has the document then they can get the changes. We know this isn't the perfect way to do, but it's the simplest way to start off with. Would appreciate any thoughts on how we can make this better. I'm on zefi@

Shameless plug for LiveLoop -- that's what we do. Keystroke by keystroke like Google Docs. Check us out: http://getliveloop.com . We support PowerPoint 2007 and 2010 right now.

I'm married to a designer who spends a lot of time in Adobe products, and her team's collaboration workflows are very similarly busted.

I've often felt like they could make great use of a version control system, and wondered why this hadn't been done before.

Good luck, this looks really promising!

It's been done for design, architecture, and engineering. There are (were, at least) specialized, integrated revision control products out there by Adobe and AutoDesk. I don't think I've encountered them in the wild, but I haven't looked too hard.

I don't think it's lack of product. I pretty convinced that there just isn't any significant level of adoption. Revision control is just an intrinsically difficult thing for people to grasp. I'm sure more than a few folks here have walked into software shops that were either abusing or simply not using any revision control.

Look at the state of the art for a product made by programmer for programmers: https://www.kernel.org/pub/software/scm/git/docs/howto/rever.... I was trying to explain this process last week. It's just not easy.

Awesome. The part about the crazy, convoluted workflow Powerpoint users go through to share changes rings so true, at least from a management consultancy perspective (I used to be one). When I was one, we weren't allowed to use Google Docs, etc, so having this directly in Powerpoint would have been the killer feature.

My inner-management-consultant-child just shed a little tear thinking about how many times I've had to redo work lost to coworkers editing the wrong emailed version.

we'd love to help!

The scale of this problem is hard to overestimate. I estimate that people collectively spend 100 billion hours in PowerPoint annually. We're tackling the same problem at LiveLoop (http://getliveloop.com)... but we capture edits keystroke by keystroke so you don't have to click "sync" to see each others edits. Somewhat like Etherpad inside PowerPoint. The other big problem we've identified is participating in PowerPoint from tablets... So we have a mobile client that also lets you see presentations in keystroke-by-keystroke realtime.

>Function: Work out what has changed

>Dev Method: git diff

>Normal Method: Open two documents at the same time, look through to work out what the differences are.

I don't think non-programmers are all manually comparing documents. In Microsoft Word, people can use any of the following methods:

- "Track Changes" when they edit

- use Word's compare documents feature

- view Previous Versions on Word Wep App

- Use Sharepoint (if they're in a large company).

I agree that version control is still an issue, but it's not like nothing exists yet. I think Microsoft or Google will probably be able to improve their version-control/collaboration tools though, so it might be hard for a third-party to beat them.

This looks neat!

edit: Document syncing beyond just the dumb hard drive approach is a market that is wide open. We saw the beginnings of it yesterday at Dropbox DBX and with things like LayerVault. Huge opportunity.

Disclaimer: I started LayerVault.

huge fans of what you guys are up to. what's the best way to get in touch?

"You should be able to sync changes without worrying about permissions or storage locations." seems to conflict a little with "We know how important privacy is, ...so no one except you and your team can ever access your files, not even us."

It seems to me that they've replaced the step of 'save it in the right location' (skydrive, sharepoint, dropbox) with 'open it with the right program'. I don't see that as a benefit at all. You even lose the normal workflow of just opening a file by double clicking it.

Sorry, we're probably not clear. You can still open your documents just by double clicking on them. If you and I were working on a deck and I stored the flie on dropbox and you on your desktop - we could both double click on the pptx files and they would open. Let me know if I've misunderstood you.

So why the convoluted method of opening in the video then, and the emphasis that I should open it as a kivo file? If I just open it in powerpoint and save changes am I still getting the versioning and updates shared to my friend?

If we have it stored in two different places, how do the changes get to his file on his dropbox where I don't have access?

So when he makes a change to the file, that edit is synced to a git repo that you have access to, your desktop document (via kivo) is polling that repo for changes and when it sees one pulls it down and displays it within powerpoint

After spending some time in the business world outside of development this is a problem I've been thinking a lot about as well.

Dropbox has slightly improved this problem but not by much.

ping me on zefi@kivo

This appears to be a git-like backend for Microsoft Office documents; initially starting with Power Point.

There are web based solutions from wikis, to trackers, and things like Google Docs and eversion allow many people to collaborate on a document at the same time (eversion does it in real time).

We're starting off where we know people really have the problem - with MS office files stacked away on old network drives. In the long run we want to integrate with any file type - Photoshop, CAD etc. Wherever there's currently v1, v2, v3, v5_tommy_edit2 we think there's room for improvement.

How do you plan to manage changes in binary files?

Office docs can be exported to xml. Wherever possible we serialise to a git friendly format, if this isn't possible we'll version the binary itself. But we'd love any tips you have!

So if you diff xml docs, will users be expected to read the raw xml diff output? Or, is there enough documentation on the file formats available so that when you diff two Word docs, for example, that you can create a third doc using Word's "show revisions" feature?

hey derek, Leo here -- I'm CTO at kivo. So, although the PowerPoint COM API is super old and buggy, the OpenXML standard which has been around since Office 2007 is actually pretty advanced. This means that you can realistically diff two versions of a file and extract and analyze the changes. The C# wrapper for this is also good (the hard bit is actually serializing the slide from COM -> OpenXML in memory). We would never expect our users to read the XML!

How would you compare this to LiveLoop?(http://www.getliveloop.com/) It looks like a very similar approach, is it just sans the real-time aspect?

(I know the LiveLoop folks, so this caught my eye.)

Big fans of the liveloop guys, great to see other people tackling the problem. For us we're trying to make UX our key differentiator, and keep things as simple as possible. Also, we're doing slide by slide version control, rather than the snapshots of the whole file, which a few other companies in the space go for. One other interesting thing to note, is that when we were doing usability testing, people seemed to prefer the idea of new drafts of a slide rather than pure realtime. It seemed to suit the way they currently worked rather than, realtime. This surprised us.

Interesting, that surprises me as well. Thanks for sharing!

Any plans on spreading this to other Office formats?

yep, we're working on word next. Sign up on the site and we'll keep you updated. Do you think that's the best Office format to tackle next?

I couldn't find anything either on your features page or in the screencast - how do you handle conflicts and conflict resolution?

At the moment we don't do anything automatic. We display all the previous versions on a slide by slide basis within PowerPoint. We don't know yet what the right way to do this is, but we'd love your input - I'm zefi@kivo.com

The ideal solution to this problem (and many others) would be using text based, human readable file formats.

That doesn't sound ideal, that sounds subpar but easier. A human readable text based PPT sounds atrocious!

This doesn't mean that people have to edit in text editors.

Anyway, having non-proprietary file formats is more important than being human readable. For this reason and others.

Like the XML-based formats that MS Office has used as its default for saving documents since 2007?

http://en.wikipedia.org/wiki/Office_Open_XML

Isn't it zipped? Can Git really handle .docs? Would be great!

scigit.com is solving this problem.

Great, congrats Zefi and Leo! This is a huge problem for a lot of real world people (non-hackers). My mom was complaining about this a couple days ago, and I told her I knew a couple great guys working on it ;)

Reply on news.ycombinator.com