4

For a half semester long project a group of five or less individuals will be working together on a project which has been distributed to them (and must be turned into for grading) as a folder of .doc(x), .xls(x), etc., files. One file in particular will see most of the editing --- a .xlsx file.

Members will be using TortoiseSVN to commit changes/do checkouts. How well will SVN facilitate collaborative editing in this instance?--e.g., how would svn handle merging of the same file edited in different ways by two different clients?

3 Answers 3

2

How well will SVN facilitate collaborative editing in this instance?--e.g., how would svn handle merging of the same file edited in different ways by two different clients?

This is dual-sided question really.

how would svn handle merging of the same file edited in different ways

Very good. It's really one of basic features of any merge-based SCMs - combine diverged history of changes

How well will SVN facilitate collaborative editing in this instance?

Poorly, because, as already noted, old MS-Office files was "just binary" for subversion, automatic merge of binaries may give unpredictable results, for manual hand-driven merges it's more question to Subversion admins, which can (have to) provide and configure special diff|merge tools for *.doc in repository in order to allow end-users do merges in usual WYSIWYG-way

For new, XML-based Office situation became even worse. AFAICR, docx|.xlsx files are really multi-files zip archives and merge can, theoretically, affect and change more than one file. I don't know how to handle this case

8
  • Essential then using an SVN repository for this purpose will work well only to keep the files all in one place, least any two people try committing differing file versions.
    – eichoa3I
    Mar 4, 2013 at 2:51
  • 1
    @jhstuckey: Yes. But then, Dropbox is much easier to setup and use
    – Thilo
    Mar 4, 2013 at 2:57
  • Would 'what can be used to collaboratively work on microsoft files' be a separate question, or is the matter simply that they can't?
    – eichoa3I
    Mar 4, 2013 at 3:04
  • @jhstuckey - it can be separate question (in order to provide definitive solution), and Office files can be used in merge-workflow: just some tricks needed to be implemented. Mar 4, 2013 at 3:23
  • Given the small group of users, and the one or two files we're going to be editing --- a solution to this might be to simply split the excel file by workbooks (since everyone has certain workbooks within said file that they'll be editing, and no other workbooks) and then re-collect them at the end. We have then version control, (svn provider gives us) commenting and other web-ui features.
    – eichoa3I
    Mar 4, 2013 at 3:32
5

SVN is not really suited to the versioning of binary files (which .doc and .xls are), as the files don't contain text it's practically impossible to diff the files or to merge changes. The newer format (.docx and .xlsx) are actually XML documents which could help slightly with diff and merge operations but would still be quite difficult.

My recommendation would be to use something like Google Docs which will allow for versioning and simultaneous editing by up to 50 users (does spreadsheets too). If your dead set on using SVN I would recommend sticking to plain text documents, I know of a few people who used LaTeX and SVN for some assignments, which allowed them to do formatting.

7
  • Thanks for your response. We can't use plain text, as our work must be returned in the format it was distributed to us---or did you mean, work in plain text, then manually copy it over to the binary files?
    – eichoa3I
    Mar 4, 2013 at 2:33
  • 1
    @jhstuckey That's always an option. I've never been all that happy with the formatting options available in Google Docs. So I usually work with the document on Google Docs with everyone, then once all the content is complete. I download it as a Word document and do the final formatting in Word.
    – Dracs
    Mar 4, 2013 at 2:40
  • specia diffs-mergers (external) can solve problem of visualisation files Mar 4, 2013 at 3:24
  • 1
    @LazyBadger, RTF is not text by any strech of the imagination, so it isn't handled reasonably by any VCS known to me. BTW, XML or such also has way too much structure (not just "independent (mostly) lines of text") to be handled correctly.
    – vonbrand
    Mar 4, 2013 at 3:40
  • 1
    I think this answer lacks an important nuance: Subversion cannot handle binary formats efficiently, but Subversion clients can be used in combination with document-format-specific comparison and merge tools - for instance, when asked to compare two revisions of a Word document, TortoiseSVN will just fire up Word in document compare-and-merge mode on the two versions. Subversion doesn't limit you here. Mar 4, 2013 at 16:23
4

Not very much. In fact, no version control system is very good at such a task, they are tailored at handling plain text files (the types you mention are all binary). You can handle them, but tasks like "show changes" or "who did..." won't have answers. And that is most of the point of version control.

Perhaps a better solution is to share documents via Google docs or such?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .