Slashdot Mirror
Ask Slashdot: Version Control For Non-Developers?
occamboy writes My spouse works at a company that deals with lots of documents (Word, spreadsheets, scans, and so forth), and they have a classic version control problem that sucks up hours of her time each week. Documents are stored on a shared server in some sort of hierarchy, but there are all kinds of problems, e.g. multiple copies get saved with slightly-different names because people are afraid of overwriting the old version 'just in case' and nobody can figure out which is the latest version, or which got sent out to a client, etc.
Version control should help, and my first thought was to use SVN with TortoiseSVN, but I'm wondering if there's something even simpler that they could use? Do the Slashdotteratti have any experiences or thoughts that they could share? The ideal solution would also make it easy to text search the document tree.
Version control should help, and my first thought was to use SVN with TortoiseSVN, but I'm wondering if there's something even simpler that they could use? Do the Slashdotteratti have any experiences or thoughts that they could share? The ideal solution would also make it easy to text search the document tree.
Easy to install, free for 20-users or less, rock solid, and clients for many OSes. Most importantly, it supports single-user checkouts, which is vital for things like Word documents that won't merge.
1) Create a rational naming convention and use that.
Or
2) use Sharepoint's (base version is free beer) built in versioning system. That is what it is designed for and is one of the few things that SP does well.
http://www.doxbox.ca/
It is a document management system
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Something like Alfresco ?
Version control works well and in usually integrated with developer tools. Document Management is the same thing, but for Office. Look into something like Alfresco or any other document management system.
I agree it's a business problem. MS Office has some pretty good versioning support built into it and multiple people can edit a document at the same time, if you know how to set it up. There should a technical person in your wife's company that understands how MS Office and other tools work. They should train the staff on the capabilities and the staff should come up with a process that works for everyone.
With SharePoint you can have MS Office documents versioned, it is basic versioning, not like git where you can have branches and things like that. For other types of documents, it's a matter of defining a process and naming convention on how to keep a track of items.
What you are looking for is a Document Management System, something like Documentum or FileNet that are built for this specific version and include additional features like workflow and extra attributes that you can add to the content to find it easier. Web Content Management systems are not the same thing, and will not work the way you want them to so make sure you look at all the options out there.
There are tools for this kinds of users, such as Documentum. Tools like this you can mount as a filesystem and use with Word / Excel / etc. It might be expensive, but it's worth using the right tool, not shoehorning them into a tool geared at devs.
please excuse my apathy
I would recommend Google docs, assuming there isn't any crazy formating involved.
#1) It is a single document so you don't have to worry about the naming of it..
#2) Google Docs has a built in ver. control, in that you can roll backwards to early version of the document, and you can see who is editing, changing etc. (assuming everyone has their own password).
It's low tech, easy to use, and the only education is to keep on using the same file name.
http://www.hawknest.com/
Lord help you if you do... It's bad enough for source code, but it's horrible for Office documents.... On the plus side, everybody has their own local repository so loosing data due to drive failures is minimized over having everything on a server, but all that pushing and puling with merging is painful on things like word documents...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I'd avoid SVN for anything that isn't a flat text file, otherwise it becomes a pain to merge or determine what the actual difference between two files is. I'm not aware of anything that will make viewing diffs for Word documents human readable. Never mind that some of the people who need to use it will probably be a afraid of it or have even more basic problems like forgetting to commit.
If they're not doing anything that requires absolute security or precise formatting, something like Google docs might work reasonably well. It's simple to use and doesn't require the users to understand the complexities of version control. No idea if there's anything that can be hosted locally in case the company can't or would prefer not to put the data on Google's servers.
I had a similar arrangement for a medical practice using Subversion and Cornerstone but ran into the same issues mentioned in the parent, creating new weird names, forgetting to check-in their changes, etc. Given the docs were Word, Excel, and Powerpoint, merges between files aren't possible.
The only real solution was to park everything online, including the editing and version control. Removing the notion of a 'file' that had to be down/uploaded was the biggest thing to overcome but they soon adapted and having simultaneous edits while everyone is on Skype was a real win for them.
Google Docs, its free and your collaborators don't even need Gmail accounts to contribute. Compared to the other offerings (Smartsheet, etc), the ability to add additional scripting behaviours puts it on a level above the rest. At that point you'll have to pay about $50/user/year which is quite reasonable.
If they are open using Google Docs, it supports multiple simultaneous editing, and does versioning of files.
A lot of us are on soylent news. http://soylentnews.org/
Buck Feta!
It's quite a lot simpler and idiot proof than tortoisegit.
I recently deployed it in a someone similar situation but we aren't really looking to do any kind of branching, just keep a set of shared files on machines in several locations that have a full version history and change log.
I still expect I'll have to go in myself and resolve any conflicts or deal with the situation where we need the version from september, but for day to day commits I think the github tool will work quite well
It has an automatic versioning filesystem (Files-11)...
Far as I can tell there isn't really a 'modern' filesystem that does this. Because what you need is for no one to have to think about doing it. Save the file, done. w/ Files-11 it gets a version number appended and if it's important enough to recover I'm sure someone would manage to figure out how to dig up the older revision that they want.
Alfresco has a versioning capability: http://docs.alfresco.com/4.0/concepts/versioning.html
What's Beta?
Taking guns away from the 99% gives the 1% 100% of the power.
If you can't afford to pay for a real solution, you should be prepared to invest an exceptional amount of time in a custom solution, most of which you probably won't bill them for. If they can afford to pay you the proper consulting amount, then they should pay for the right software. If you're willing to dedicated an exceptional amount of time, you can make something like SVN work. To do it with something like SVN - to do the training, to set up the automation, etc - it will likely take WAY longer than you think. And then it will likely fail. Or, it will work and you will be forced to support this until the end of time. If you're getting paid, that's awesome. If you're not, it sucks.
So what I recommend is:
----- obSig
The greatest document version control solution will ultimately prove to be useless without considering the human, i.e. user, part of the solution. Unless you have clear procedures in place detailing how to maintain version control, teach people how to use the software, explain to them why version control is important (and yes that means you, Mr or Ms senior executive who doesn't have time or the need to follow procedures that are in place to prevent the last screwup you caused by ignoring them), and have someone who maintains the document library and keeps it in shape so it actually is easy to use, your solution will fail. Without that, people will download the latest, make edits, save a copy and upload the edited version. After a while they will simply edit the saved copy and, if you're lucky, upload it as a new document.Others will download a document, make edits, save a copy and send it out without ever checking the document back in so no one else can edit it; those people will find an older version and simply edit it.
I've been there and seen it done very poorly and very well; the key difference is those who do it well have someone who knows how to make it work, can educate people and convince them why it is important, and actually make it work. Those where it fails simply put in a technology solution and then wonder why it didn't works they search for the next technology solution.
I'm a consultant - I convert gibberish into cash-flow.
1. Document the number of hours lost in a week for version control issues by your wife. Ensure that your data is representative of several weeks worth of work
2. Extrapolate this value by the number of people in the company and the number of weeks worked per year
3. Multiple this by the average hourly cost of these workers (the gross value to the company, not the net value paid to the workers)
4. Write a report that documents the $$$ lost to the company due to bad business practices. Include in that report a survey of possible technological and social solutions to the problem and document their estimated cost to the company.
5. Make a presentation to the CFO and CTO explaining how you can save the company big $$$
6. If the CFO and CTO care about the lost $$$, they will create a new project number that you can bill to in order map out the preferred solutions in your report
7. Implement your preferred solution for a small group and measure how much it costs the company in real $$ in order to implement this pilot project
8. Write a new report to the CFO and CTO documenting your findings, and make a report
9. Sit back and wait for the CFO and CTO to argue where in the next budget the money for your solution will come from, versus doing nothing and simply wasting money that has already been allocated.
What do you mean you don't work for you wife's company?
I am Slashdot. Are you Slashdot as well?
GIT also does checkouts/checkins a lot faster than Subversion. Usually 30-40 seconds vs. 20 minutes or more for Subversion.
I do not fail; I succeed at finding out what does not work.
This. Either use Google Docs or Sharepoint or whatever. There are also document management systems that run on the server side like Alfresco.
There are dozens of document management and document version control systems, and many enterprise content management systems have document management as a component. The most well known is probably Microsoft SharePoint, but there are open source alternatives like LogicalDOC, OpenKM, Plone, Nuxeo, Alfresco, etc. as well as other commercial offerings like IBM Enterprise Content Management and others.
However, the technology won't replace poor training or users determined to do their own thing.
The road to tyranny has always been paved with claims of necessity.
If you are on OS X, I've found Draft Control to be fantastic for versioning docs. It's essentially an easy to use UI on top of Git for your docs:
http://draftcontrol.com/
I'm guessing their IT staff is someone who knows something about computers and much of the staff isn't too tech savy. To keep them from going nuts, use Sharepoint. They can version control their documents/spreadsheets and edit them at the same time.
I don't think this would necessarily fit your needs, however you might find it as interesting as I do, it's more geared toward authors, but it's a custom baked thing that a pal Cory Doctorow's whipped up for him to use Git for his writing http://craphound.com/?p=2171 Like I said, it doesn't seem like it would fit your needs, but it's interesting and I thought I'd share. I do think there's a lot to be said for user education. It doesn't have to be ongoing, but just sitting down once with several groups of people can work wonders on an offices workflow.
I like how the content was removed to make room for the whitespace. Awesome.
or confluence, alfresco.. or most other CMSs.
You left out:
5.a Spend an inordinate amount of time explaining and defending your estimate to the point the CTO and CFO forget about the initial problem
Delete steps 6 - 9
I'm a consultant - I convert gibberish into cash-flow.
I've been using SubVersion since it was in beta and have used it at work and in private in multi-gigabyte projects. SubVersion was always rock-solid for us, and it's handling binary files very well (which was the prime reason we decided to switch use SVN back then in about 2003). Git is an excellent tool for us developers, but I feel it's way too complicated for non-technical people who don't need these bells and whistles.
Sounds like the underlying problem is poor planning / lack of communication / clear guidlines for developers to follow so they are not working against each other. Fix these problems with the existing solution. Don't add another layer that only one person uses / understands for doing their work. That approach definitely works for the individual but multiply this for every team member who (doesn't like/is confused by) the existing solution and you've got a much more significant devops problem. Additionally bringing on new team members and getting them to be productive will take much less time if the root of the problem is resolved.
The problem you have is a "process" problem. If everybody is editing documents all over the place at the same time on shared drives, you simply cannot avoid the *real* problem and that is a process one. CVS or RCS, or any other "version control system" cannot fix the process problem.
You need to think about why the "process" allows multiple people to be editing the same document at the same time. If you continue to allow this practice, your issue becomes a question of "how to merge" all this input back into ONE document. Unfortunately, Merging is pretty much *always* guaranteed to be a hard problem, especially when you are merging things that are complex in structure. Source code is bad enough, but you are dealing with stuff that most revision control systems just store as binary blobs and can usually only tell you that copy x is different than copy y, but not what the changes actually are.
So, your FIRST responsibility here is to solve the problem with your process that leads to multiple editors having the file open at once and pare that down to the minimum number of editors you can (hopefully ONE at a time) and then deal with the difficult merge task that's left. I'll warn you that you may need to enforce the process using file permissions, only giving limited people write access to the file on the share so only they can change it. Everybody else has to go though them.
THEN, you can implement just about ANY revision management system you want, or if your access controls are well enough established, just keep everything on a common share that everybody can read, but only by going though the process can they change things... If you *must* have revision management, go with something that can parse the internal changes of the files you store as much as possible. For Office documents, I would assume Microsoft has tools for that, beyond just sharepoint...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Oh, now, come on. If you're just using GIT for the basics, it's a matter of changing the name of the command you're running. It's not "harder" to use than Subversion -- it just has extra features you don't have to use.
I do not fail; I succeed at finding out what does not work.
One decidedly low-tech thing that can be done without any other changes is to have your users start saving documents with sortable times in the filenames, updated as to the time they are doing the save:
client1-document-20150217114003.doc
YYYYmmDDhhMMss
If that's done with a save-as, they get the previous version safety they seem to like just by using "save as" intelligently, and they get latest version sorted using just alpha sort, so it cuts down on the confusion factor.
It isn't much effort, but it's surprisingly effective.
I've fallen off your lawn, and I can't get up.
While you cannot use the merge features and the like for non-plain-text formats, I made good experiences with word, PDF, etc. in SVN repositories. It does require coordination in a different channel for collaborative editing, but it gives you the central things needed, namely a history that allows you to retrieve all old versions and a change-log.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Practical experience over several years with projects in the 7-12 million line size. Subversion chokes on large projects whether you fanatics like it or not. GIT was *designed* for large projects and does a much better job of handling them.
If you're running Subversion over the internet, it becomes dog slow for large checkins.
I do not fail; I succeed at finding out what does not work.
Which is not a version control system at all. Time Machine does periodic backup once per hour, and only once per hour. Not on each save. Not multi-user. No mod points for you.
Sig?
And adds another: Sharepoint.
Libreoffice has flat formats that are text-editable (xml ish), suitable for version control to some extent. So git is ok but you need to switch the entire system in order to use git. That being said, if the changes are required to be tracked like that then yes it will be a better solution.
I would use Worldox as a document management solutions. It works with every application I can think of and is inexpensive. It can store 24 versions of a document and documents can be grouped together.
I have been using it for 15 years and can't live without it.
Now you have to tell us how you would force an entire medium/large business workforce that is keen on using the Office suite to switch to Docs... Or even let us know how to include no-to-exotic stuff like SGPS documents, Photoshop, Illustrator, XPTO and whatnot in that kind of version control. Docs is no silver bullet to kill Office, nor Dropbox, nor . It wasn't made for any of that, just like Google+ wasn't made to kill Facebook.
No. You are wrong.
Git handles text files well.
Git handles infrequenly changing binaries well enough.
Git handles frequently changing binaries very very very poorly.
Plus, with either svn or git, you are basically asking each user of the system to download all revisions of all files ever used on your system. That makes perfect sense for a codebase. That makes terrible terrible sense for business documents in a shared pool.
Git and SVN are different products. SVN is centralized and git is distributed. If you want to create a centralized repository and only allow people to have access to certain parts of it, SVN is a much better fit for that workflow. Neither allows the user to browse the document repository with first checking it out. Well, they both have web interfaces, but those don't support a good editing workflow.
Now you've got into rant-mode, sorry. I really hope non-technical people are never forced to actually type in commands but use a GUI instead, no matter which VCS they use. But especially with Git. I think Git is a very powerful tool and have come to like it for its features, but I still hate it for its commands and what I feel are inconsistencies and "fuck how other VCS are naming it, we use something different".
For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout -- .". WTF? Just a few days ago, I wanted Git to give me the diff of specific commit, the equivalent to "svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb). Or "git diff-tree -p revision" or "git whatchanged -m -n 1 -p revision" since why not? And "git add" both adds a new file to the repository but also picks a modified file to be included in the next commit (but only the parts that have not changed between add and commit. The add behaviour does make sense when you think "from the inside" of the VCS, but I was confused at first and I'm a technical guy. Normal people will have trouble with this stuff. Seriously, I've been using various VCS in last two decades and still am doing a lot in the shell, especially VCS stuff since I feel to be more in control this way. But Git is the first VCS that I use almost exclusively in a GUI because it's CLI is too cumbersome.
I know that Microsoft products aren't hipster and all, but the OP mentioned Word and Excel documents. SharePoint supports version control. I don't know how well it works for scanned images, but for documents and spreadsheets it works just fine.
Love sees no species.
GIT also falls down when the project gets large enough, which is why it's not used by Google/Microsoft/Amazon for their larger projects. For that you'll want something like perforce (which is admittedly a bit painful). Though somehow I doubt they're making nearly enough documents for that to matter.
One big problem Sharepoint can have - If you open the document from Sharepoint and then your office application crashes out (which used to happen fairly often with some macro laden Excel spreadsheets my company has used), then you have two problems: 1) There usually any autosaved version to recover your changes from 2) The version you were working on from Sharepoint is locked out by "another user" and can't be reopened for editing. It's possible they've fixed these issues in the last few years, but I doubt it.
Um, your problem is trying to version control office.
Stop using it.
Put up a wiki.
You're done and just saved the company several hundred thousand dollars a year in licensing.
The company I work for just rolled out a cloud-based storage system that has version control built in. The company is Egnyte. Their solution allows us to maintain local copies of our files, with version control in the cloud. So this solves our versioning issues as well as disaster recovery. Changes made at one of our five offices get uploaded to the cloud automatically and synched back down to local copies as well. Good luck!
Have you ever split a large project into several components stored in different repositories and tried to keep them in a consistent state? Like, trying to rebuild a version exactly as it was one year ago because a customer needs a very specific fix for that version? I've come to learn that especially with huge projects it can be a very good idea to have everything in one repository.
If you consider SVN, GIT, or any code optimized source control, don't forget that many business users rely on the last date modified attribute of the file to determine versioning. Many source control systems don't care and don't store file modification dates (they store check in dates instead). This can be a show stopper. While as technical people we want to force the concept of version numbers on folks, it is just not in the culture of many business types.
I've worked on a SubVersion project for several years where the smallest useful checkout was 5GB (it was an in-house Linux distribution I've built and maintained). On a local network, SubVersion works pretty well for these things but you're right, I wouldn't want to do this over a poor Internet connection. It's pretty space efficient with binary files and handles things like copies and renames very well, so if you need to deal with them a lot then SubVersion is a good choice. Git and SubVersion work very differently, each have features the other doesn't have, by design. Believe it or not, SubVersion was also *designed* for large projects, but different use-cases. I really, really wouldn't want to maintain my distribution with Git. Now that I'm a "normal" developer again, we're using Mercurial and Git since they're better suited for these tasks, handling source/text files with lots of branching and merging.
http://www.opentext.com/what-w...
Disclaimer: my cousin works there.
- Michael T. Babcock (Yes, I blog)
ownCloud(https://owncloud.org/) supports versioning and will automatically sync changes. It's easy to set up on your own server.
You can set up Apache to serve files over WebDAV. WebDAV is mountable as a network FS on Windows, OSX and Linux. Apache can store the webdav files in an SVN repository, so you get file versioning built into the mounted filesystem that is completely transparent to the user.
You can also set up apache to allow normal browsing of the SVN repo, so you can browse it online without mouting and also access old versions.
So basically you get transparently versioned files. Native read/write access. Access to old versions via a web browser. No tools required on the clients for it to work.
Also all free and open source and the data is not stored in an obnoxious format that it opaque: it's a refular SVN repo and works just as well with commandline tools.
SJW n. One who posts facts.
Configuration control is all about the methodology, and not about using a particular tool. It is possible to have great configuration control without using any software tool, and it is also possible to have no configuration control while using a software tool.
The simplest solution in the above case is to put into place configuration control procedures while not using any software tool.
Most developer VCS are overkill for a business environment. Do you really want to have to explain branching/merging or *gasp* rebasing to an office temp? The ideal system would require initial configuration and then create versions automatically.
Candidates: * Dropbox or equivalent. Good choice. Automatic backup and versioning. Reasonable per user / month pricing ($15/user/mo) * Sharepoint. Love it or leave it.
Individual users can turn on the versioning features of office, but since no way to enforce that behavior, good luck.
http://www.makeuseof.com/tag/not-just-for-coders-top-version-control-systems-for-writers/
That is why I usually recommend Subversion - because you can just mount Subversion like a network drive since it uses WebDAV as its base protocol. I've done that with several managers and it works well.
And there's no additional cost.
The problem now, though, is that Microsoft is removing their WebDAV FS drivers from Windows.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
One way to do this with SVN is pegged external directories. You tell basically tell svn to pull a directory from a different repository at a specific version. The information about which repository and version to check out is itself saved in svn, so doing a single "checkout this revision" will give you the entire codebase as it was at that time period. It's complicated, and manual, and time consuming, and it kinda sucks. But it does work.
It occurs to me that NTFS actually is supposed to have file version support built right in, even arbitrary file forks.
Isn't this accessible to the users in some usable way, and if not, why not?
A great resource for situations like this is Turnkey Linux (http://www.turnkeylinux.org). They host a wide variety of fully built server images that make it easy to try out a number of systems to see what best fits your need. You can download and fire up well known CMS like Drupal or plone and see if they fit the need or not. Then if there is something they like they can load the iso on a bare metal box and go.
Average Intelligence is a Scary Thing
I imagine it is hard to be a corporate whore.
You may be one already and not even know it!
Taking guns away from the 99% gives the 1% 100% of the power.
All versions are saved and accessible from phone to desktop.
Probably people will downvote me for this, but this exactly scenario is why SharePoint exists. It's specifically to help non-technical users post, share and have version control for their office documents.
It integrates with Microsoft Office, so Word etc. simply presents a 'check out' button on the top, and asks you to 'check in' if you press the 'x' and try to leave, and you can add comments.
Don't know why this wasn't considered?
Most developer VCS are overkill for a business environment. Do you really want to have to explain branching/merging or *gasp* rebasing to an office temp? The ideal system would require initial configuration and then create versions automatically.
True. I think what is more, the RCS should operate within their file server, without needing to set up a server on its own. That is, all it need to do is to maintain a hierarchy (or less preferably, a database-blob) in a locally accessible driver.
That's because I have a hunch that what they have for file server is just a NAS-box (everyone uses the same account). All is not lost how ever, as as most NAS-boxes support FTP, so configure a separate user for the RCS and configure the account into the RCS so that people would no longer mess with the hierarchy by hand all the time. (It's not real protection, just a speed bump, but that is not needed in a small office.)
I don't know any system personally, but found by google that GNU Bazaar does exactly that sort of a thing. I have to thank you for this, I'll definitely try to set up Bazaar at the office at some day, because we too have this everyone fucks with the same NAS kind of thing going on.
Considering that the most commented on article today has 44 comments (not uniqued by user), I'd say that "a lot" is stretching the truth. Besides, if it was really all that, you wouldn't be here trying to talk about it.
You're special forces then? That's great! I just love your olympics!
Did you even read the question?
I've never seen a version control tool which is less intuitive for a new user than GIT. It has horrible support for binary blobs and documents. Windows support is an afterthought.
GIT is the right tool for you only inasmuch as your needs mirror those of Linux kernel developers. That covers some of the universe but not all of it and not any part of the universe represented by the original post question.
Git has the "stage", right. The stage is just the next commit. It's a little hidden filesystem (git tree, actually) that's already processed and ready to be attached to a commit message once you run `git commit`.
For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout -- .". WTF?
`git checkout` is about your working directory. Use "git checkout -- foo.bar" if you made a modification and you don't want to commit it, just erase it. Or better yet, `git checkout -p`
`git reset` is about unstaging changes, it doesn't touch the filesystem. (It also has `git reset -p`)
Just a few days ago, I wanted Git to give me the diff of specific commit, the equivalent to "svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb). Or "git diff-tree -p revision" or "git whatchanged -m -n 1 -p revision" since why not?
You want to see the changes that one commit introduced, so of course you ask git: "What were the changed from parent-of-'$revision' through '$revision'?"
You're probably looking for `git show $revision`
And "git add" both adds a new file to the repository but also picks a modified file to be included in the next commit (but only the parts that have not changed between add and commit.
`git add` copies a file from the working tree to the stage (index). What happens when you use `cp` and the target file doesn't exist? It gets created. (Since you can't copy a nonexistent file, there's also `git rm` to remove files from the stage.)
Wonder what the public key field is for?
My experience with SharePoint: A) it does not protect against multiple check-outs followed by multiple check-ins erasing other people's changes. Basically there's no detection of collisions between your changes and changes since you checked out. This caused a lot of grief in my work group. B) The versioning is strictly linear, at least I never saw any branching. That is very unlikely to address business needs. So you will need a naming scheme to represent branches.
" basic versioning"
.BAK file name. The .BAK files can be in a special folder.
The free Notepad++ can make a backup of every save, with date and time in the
To lose changes to a single file: git checkout foo. To lose changes to all files: git reset --hard . To see changes brought in by a revision: git show revision (unless it's a merge).
I like the versioning on Sharepoint. It's the best thing about Sharepoint. But, Holy Jesus Christ... Sharepoint sucks to administer. I'm not a dev, but I had to help set-up and run and on-prem site; and unless you've taken a class or gotten certification on it, it fucking sucks to setup and maintain. But man, I do like the versioning! If I only ever had to be a user of a site that someone else administers, then I would forever be OK with that!
Give a man a fire and he'll be warm for a day. But light a man on fire and he'll be warm for the rest of his life.
The strangest thing is that OS X has file versioning built in regardless of whether you choose to use TimeMachine for backups. Perhaps they don't understand the difference.
I think that 1 of 2 things happened: 1) Apple uses Time Machine in their versioning of iWork or 2) Apple took the same interface from Time Machine and integrated that into their versioning system. If it's number 2, it's easy to see why someone could make that mistake. Either way, iWork kinda blows and the versioning in OSX doesn't work with MS Office. The best you could hope for with Time Machine is to restore an earlier version from a few hours before.
Give a man a fire and he'll be warm for a day. But light a man on fire and he'll be warm for the rest of his life.
My wife and I use MediaWiki! Seems kinda silly - but you can configure it to accept all kinds of file types - and you have all of the nice stuff like discussion pages and categories to help you to organize them.
The huge advantage is that it's insanely easy to use. Super-light on features also...but, hey...it's a thought, right?
-- Steve
www.sjbaker.org
1 - Switch to Office 365 or Google Docs in which revisions are a built-in feature of document editing
2 - Enable Office's built-in version tracking
3 - Move all document storage into a CMS like Sharepoint (which has good Office integration at least on Windows) or BaseCamp, Jive, Confluence - any system that allows for online editing and has revision tracking built-in
Any other ideas, skip. Anything having to do with a source-code like version control system will result in people "committing" but duplicating files over and over in the old pattern.
I'm out of my mind right now, but feel free to leave a message.....
My Gig currently is with a classic marketing agency. Very nice folks - a breath of fresh air when it comes to my history with agencies - but breathtakingly clueless with IT - as usual in this industry. I'm basically the only IT/dev guy in a shop of 30. Has its ups and downs. ... Whatever.
They asked me on board as a webdev, to establish a pipeline and introduce versioning. I'm using Git on a VMed central linux system and SourceTree as client. Our outside SSH port is mapped to that VM, so the the people on a project can commit docs or code on the go.
Sidenote: I wouldn't use anything other than Git, it's just not worth it. Git has won the versioning thing. End of story. ... Bazaar might be an alternative, if you need the same click-ui on windows, mac *and* linux, but that is probably a very rare case.
As a client we use SourceTree on both Mac and Windows, so all UIs look more or less the same. No Tortoise, for that exact reason! I show them where to click to see the entire file-tree as in finder or explorer, so nobody is confused and explain the difference between a commit and a push. In a pinch, the windows and mac folks can help each other out if I'm not around, since they’re all using SourceTree. And it keeps this "Versioning" thing nice and secluded. That's also a reason.
I want to get them to use versioning, so I tell them #1 is always fear of using it. I tell them not to worry, it's pratically impossible to break anything (one of the advantages of Git). I tell them to version often and comment their commits, even if it's just smalltalk. The point is getting used to commenting. We don't uses branches, just master. I also tell them to try and logically group commits, but not kill themselves if it goes wrong. It happens - with me aswell. No harm done.
Once everyone is pro in versioning, we might change the branching policy.
As for all the other buttons in SourceTree, I just tell them to ignore them and that they are for later. I do tell them the meaning of "Stash" and how nifty that is when you've forgotten to pull before starting your work, but only those who need and want to know. ... As soon as they get a pull conflict, they ususall do want to know, so no problem here.
I've established a naming-standard with ProjectFolderName/git-repo for local clones, so everyone has a space where they can fiddle for the project without needing to inmediately version if they just want to try out a new tool or salvage an older Photoshop template or something. Project docs go into /docs, developer stuff goes into /code (mostly complete wordpress installs or some other thing), DB dumps into /db, graphics, layout, DTP files and videos and other raw material usually goes into /assets, etc. ... You get the picture.
We're/I'm not to strict with dir-policy and let it grow a little too. No project is like another.
Important:
I put my agency behind versioning, because right now its Filename-02122014-final-extra-specialEdit-Peter.doc on a central drive and shit. Especially with the editorial team. Not good. I did a neat presentation and help everyone who comes into versioning to get familiar with the concept. Installing SourceTree, doing a few demo commits, have them do it, show them the red numbers, looking at the history log and file-changes and stuff.
A few months in and the online team is starting to get used to versioning on some projects. Once everyone there is on board we’ll move into other departments. My PM for one large online project is using versioning regularly now, as are the students helping out. That the bosses are behind all this helps.
Sidenote: More than half of the team is ladies, as is my PM, btw.
I tell everyone that they can ask me everything a million times and call me at 2 o’clock in the morning if it’s a versioning problem and they need my advice or some handholding. Very import
We suffer more in our imagination than in reality. - Seneca
This is NOT a technical issue that new software will solve. It is a training or management issue. If people don't understand how to use version control, they will use it like a file share instead. I've encountered this MANY times, and right now I'm struggling with the idiots (actual software developers) that are using dead-simple SubVersion tools and STILL want to make copies for new versions, create new folders for the "current" docs and rename folders as archives. Constantly. And these are supposed to be DEVELOPERS! They seem to have no concept of tagging, branching, or even versioning in general. WHY did you delete all these files and then commit a bunch of modified files into a new folder!??!?
The only way to fix this is to create some policy and procedure documents (they can be really short and simple), and then get management to ENFORCE them. Otherwise, you might as well just throw out the version control system and let everybody do whatever they want in a shared store. Because that's what they'll do anyway if they don't "get" version control.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
I helped grow an engineering company from 3 people to 25 with a mandate to provide for satellite offices and remote non-technical workers. SVN/Tortoise was the hammer I chose, because it was the only hammer I knew at the time that was even vaguely like a Document Management System.
It solved many of the basic problems, but it has not been without pain. Try explaining to a receptionist how to mitigate a tree-conflict error that she didn't cause. Worse, explaining to the satellite offices that video files require an entirely different sharing mechanism simply because they're big. To the president that his edits don't get priority over the guy who committed first.
If I had it to do over again with a shoestring budget, I'd probably do the same thing. But I'm here in this thread because I'm hoping there are better answers for people on the Linux server - windows client model, who have grown to the size where they have an IT budget, and place a high value on uninterrupted productivity.
So seriously, are there anecdotes from mid-size companies trying to solve the document management problem?
I'd love to see you explain all this to an average office lady :-)
The 125-page book "Introducing GitHub" by Bell and Beer published by O'Reilly in November 2014 is a great introduction to version control and GitHub in particular for non-technical people. It is specifically aimed at an audience of project managers and product managers. ISBN 9781491949740. Well worth the twenty-five dollars, and the quiet weekend you will spend on it.
We don't think its an acronym, we are SHOUTING. We don't use Git cos we have tried it, and didn't like it. At all.
Sent from my ASR33 using ASCII
Dang, me using the incorrect case of the "v" suddenly destroyed several years of experience? Oh gosh, and I thought actually following the mailing-list for several years since the betas and reading about how and why those people designed the tool would give me some understanding about it, but you're right: spelling is way more important.
Where I work we use smarteam for exactly what the questioner wants. We design certified products and have to control and track documents. It is purpose made. It enforces single user check out, flow processes for document release approval.
For source code we use other tools.
Seriously. I've been here. Imagine the worst kind of software developers - people who don't check in regularly and when they do they smash a huge delta into the repository. Imagine people who don't really understand version control and manage to screw up the tree with their own little "experiments" on how they think things should be run.
And best of all, imagine who they will come to when things go awry. Do you want to be that person?
Foisting sophisticated tools on technically unsophisticated folks will end in tears. Use an enterprise document management tool (Alfresco, Nuxeo, Sharepoint, etc) and lock down the workflow. Yes, there's still a learning curve - but expecting non-developers to grok development tools is a path to pain.
We use Google Docs. The documents a live on the central server and there is one version which everyone can simultaneously access. All updates/changes to the documents are logged and you can revert changes very easily.
Finally a question about a problem where I can say "My company no longer sucks at this ....".
1. Before sending out an MS Word (or similar document), one needs to remove all of the change-tracking information. That is, unless you want the client to be able to see and read all of the changes, who made the changes, and any comments that went with the changes. We had a few hiccups ... so we made it "policy" to converting every MS Word document to a pdf.
2. We used a CRM (Customer Relationship Management) product that stores all documents sent to a client (in addition to notes, follow-ups, etc.)
3. For standard documents there is a subdirectory which holds all past versions with titles that include dates and reference to the client. Disk space is cheap.
About seven years ago I was part of a star tup of technical writers for military manuals. I had worked with this group at our previous company and the group had many of the same problems, lost files, changes occurring that 'just happened', incorrect versions for delivery. The files were in SGML/XML, with supporting graphics, so a little different but the users were not software types who are used to digging in and figuring out tools.
When the company was setup, I was designated as the software support/IT person and I put my foot down, we were going to use version control. I selected SVN, using the TortoiseSVN client and I set up the first repository. We also had to share data with another company so I had to do some training and also provide support for this company long distance.
The first few months were a never ending set of complaints of how hard it was to use SVN, why is there is an error message when I try to commit, this is painful, we should go back to using a shared server drive, etc. I stood my ground and waited.
Then, it happened, one of the authors had accidentally overwritten a file that he had spent 2-3 days working on. In addition, the tech writers were learning a new way of tagging so there had been a lot of restarts and do overs and no one wanted to start from scratch. I came over, asked him when he had last committed and if he was okay with over writing the current file. He said yes, so I pulled out that last good version. After the tech writers looked over the file, he reached over and kissed me, a first for me. There were some more incidents of changes, someone overwriting another files, but most of the writers had some benefit after several months of use. After that, the complaints went down and we continued using the system I had setup.
Later on we used SVN to share files with the other company, including Excel documents used for tracking, a Word document for the style guide and other things. Now, 7 years later, the tech writers ask me to set up an SVN project when we start something new because it has saved them a lot of grief over the years.
In addition, the other company is now slowly implementing throughout their company because they have seen the difference it makes. I talked to the manager we had worked with a few years ago, she asked how difficult it was to setup. She wanted to set it up for other projects because she had noticed they never lost files, they always had the right version for deliveries unlike other projects. I was amazed to hear that entire directories had disappeared on other projects and they had no way of telling who had caused the problem
I have looked at other document management solutions over the years and I have been interested in possible solutions but SVN has always won out because of 1) No licensing costs required and 2) Low maintenance for myself and training time for the tech writers. I hate to spend a lot of extra time tweaking things, just because and the other company doesn't really have a lot of resources for that either so SVN works for our situation.
If our projects grew to a larger size, I could see looking at other options, but that would also mean that we would have more money for software licenses, help, etc. If it's a small business, without a lot of budget or expertise for version management or document management, there are worse things to use than SVN with the TortoiseSVN interface.
I used to be an adult but then I grew up.
For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout -- .". WTF?
You can use "git checkout foo.bar" and "git checkout ." respectively.
"svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb)
I don't know where you're getting those commands, but "git diff [revisionNumberA] [revisionNumberB] filename" works for me. If you want to diff with HEAD, then leave off one of the revision numbers.
I don't know why you get so confused with git, but it looks like someone taught you wrong.
"First they came for the slanderers and i said nothing."
Just riffing here but what about the idea of a "noobgit" client that checks out a given repository and every 5 minutes in the background it does a git pull, performs a permissive merge with some additional smarts (e.g. for Word docx it just keeps both versions of the conflict section and inserts a Word comment at that point), and then commits the new file? For all intents and purposes it would just function like a multi-user Dropbox. This could even use the same git server as the engineering team (though obviously not the same repositories).
I know it's not full versioning but I defy you to teach non-developers how to deal with svn, git or other such tools.
Just offering insights that it's possible to use incremental backups as a means to revert to an earlier version.
Have a master document and leave it up to the head tech writer.
Hard copies, red pens, document imaging system.
MS Office are basically some XML files on a zip. A VCS designed for them can do version control. Of course, Excel has had five or six different document formats already, so there's no telling what they'll use next year.
Sparkeshare (http://sparkleshare.org/). Or SnirtLab's (http://versionrocket.com/) plugin for Word/Excel/PPT. Or Rev-Vision (http://www.rev-vision.com/) Box has a versioning system, but I don't think it is very good - http://paulhammant.com/2014/10... There's more coming in this space too, shortly.
Use sparkleshare on the desktop pointed to a private git repo. Paid github or a gitlab server.
Every save is an automatic commit. Versions are available with the web client or git gui client. http://sparkleshare.org http://github.com http://gitlab.com
This is what Laserfiche is designed for. I've never used it myself, but know a bunch of people that work there, and it seems like it's designed to handle this problem in a way that nontechnical people can understand and with cost that scales.
And there are a lot around. Any reasonable quality management system is going to have a document control system.
2 factors make git a bad choice here :
1. Git encourages merges. Even to someone used to source code version control, the branching and merging in git is a bit too easy for comfort. And it is by design - anyone should be able to completely clone a repository easily, keep rebasing while working, test all changes locally and then merge.
2. Even many so called "MS word experts" are not really experts in branching, diffing, merging files. Excel is even worse. While I don't doubt there are tools Microsoft , and probably even others, provide for making these activities simple. But I haven't come across any experts that are really confident doing it hundreds of times a day.
This coupled with MS Word's insistence on "saving" even cursor position changes makes life even more difficult. I am sure there are solutions to this which probably the experts know - but intermediate proficiency MS Word users typically suffer from this.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
You see that string of 16 digits? Yeah, that's not going to happen. Also, one mistake, and that version is lost.
Ok, so yes a traditional document management system could be the correct way. However if you prefer the Google docs style approach, but wouldn't like the idea of it being in their hands or any other cloud file storage. Then just put in some software called Owncloud. It can be hosted any where you like. You don't have to use anyones cloud services and can be installed on a server internally. It has version control on files and works just fine. There are choices out there and if a document management system seems too much, then a file storage like Dropbox or Owncloud for example might be preferable by you and your users.
Git stores office documents as blobs because the commonly installed merge tools do not support Office documents
Why not? Both modern Microsoft Office documents and ODF (OpenOffice/LibreOffice) documents are zipped collections of XML files.
As indicated herein, the company could use Dropbox with the Packrat added feature. With Packrat, each and every past saved version of a doc are stored on the cloud and can be downloaded at anytime.
-- I fear explanations explanatory of things explained.
Perhaps I should clarify, I mis-stated the situation a little: You can "read-only" examine a file without checking it out. (We were using Excel.) In that case there is a check-out button that shows when the document is open. If you try to press the button and someone else has it out, true, you can't. But then they check in. THEN you can check it out with the button. In that case you are still looking at the file you "read-only" loaded, but now you can edit it. Then you can check it in. During that process, you did not receive the OTHER check-in, and you wipe it out.
This happened to us a lot. Like I said, we were using Excel. It might be that other tools like Word might update the file when you check it out, but Excel surely does not.
Try Confluence; you should be able to to obtain a 10$ - 10 user licence, very cheap entry cost. Give it a shot, it may do the job for you.
For engineers, I wish it was possible to setup confluence v3, because it actually had a wiki markup language that worked great and did not suck!
This particular problem is very near and dear to our heart, and something we continue to see in companies both small and large, sometimes company wide, sometimes limited to a specific department or division underserved by whatever their IT has provided for them. We've spent quite a bit of time talking to people with exactly this problem and if you like what you read here, please contact us, because we'd like to offer an alternative that hasn't yet been mentioned. And if you're wondering about the plural pronouns, yes we're a startup.
The responses so far represent the usual dilemma when trying to establish a workable system of version control that can A. handle native desktop Microsoft Office and B. Remain appealing for non-technical users, with a minimal impact on their existing workflow.
A non-technical user suffering from poor version management will never ask for version control, they will tell you "I can't find the latest version of a document, I don't know who touched it since I last worked on it nor do I understand what changes have been made since I last saw it."
Solution 1: Is to go the parallel route - simultaneous editing, Google Docs or the like. That requires leaving behind Office entirely, and being comfortable with your docs belonging to Google. There is Office 365 which may be more palatable, but you leave behind desktop Office. There's one problem with the simultaneous edits though, as documents get complicated or the number of contributors rises dealing with change management becomes a huge problem - especially if inadvertent edits are significant. Also the version must be centrally stored, usually in one and only one cloud service belonging to the authoring app.
Solution 2: Is to go the serial route - using classic enterprise document management, with a master document check-in/check-out model. Most integrate with Office. Usually it adds a lot of interface to the workflow - to find and check out the document for editing. It's a serial process, when the document is locked, everyone has to wait their turn. So you trade the accessibility in solution 1 in the name of change management, but it's the opposite extreme in every way. Not to mention most solutions are either rather expensive, and/or require significant configuration and maintenance. And central storage is key, so portability is problematic unless you can tolerate long check out periods.
Solution 3: Is to leverage true multi-user version control, with forking and merging. Furthermore distributed systems provide storage independence. All of these tools are designed for source control, though they can be adapted. The interfaces and terminology are overwhelming for the non-technical user, and the process, while sublimely flexible is frankly overkill for document workflows. Then there's the non trivial exercise of conflict resolution, when the document is not simple text or some variation thereof, i.e. markdown or LaTex.
For many none of the solutions are viable. So they stick to some method of protracted suffering through filenames, folders, shares, and/or emails. Lots of aggravation ensues.
We like to think there's a forth option - one that integrates straight through Office so all people do is save, but is robust enough that we make both filename and storage location irrelevant - but still intelligently binding versions together in a way that can be inspected and acted upon at a glance to answer the who, what, when questions easily - all without threatening overwrites OR blocking access. Not trying to turn this into a commercial, but we're looking for exactly these types of cases to help shape our nascent technology going forward - it's reached an alpha state. Message us if you'd like to take part.
And what if you could?
There is room for something in-between, more robust than simple timestamp versioning, but easier to deal with than full-fledged source control.
The built-in versioning that the AC is referring to was detailed by John Siracusa in his Lion review. You can see that it is a close cousin of Time Machine interface-wise, so it is easy to mix them up.
I'll agree with you that anyway it is not the solution the poster is looking for anyway, for a number of reasons.
http://en.wikipedia.org/wiki/D...
"but I'm wondering if there's something even simpler that they could use? " Simpler and for the end-user you have mindtouch (an open-source wiki ) and with control-version for all your files on the desktop. ( http://www.mindtouch.com/ ) As Leornard Da Vinci said "Simplicity is the ultimate inovation" Francisco Gonçalves
Francisco Goncalves ITconsultant & Open Source IT Technology Advisor mobile +351-96-230-2583