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.
...or some open source flavor of perforce or sharepoint.
http://www.doxbox.ca/
It is a document management system
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
It's called Sharepoint, and you can give microsoft money to get it.
Or, you can research alternatives to sharepoint, but that's basically what they all do.
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.
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/
I thought version control for the masses was last OSX's automatic saves feature with history keeping. But there is much teeth gnashing about not being able to control when stuff is actually being saved/versioned.
Handles all of those problems.
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.
Easy version control for docs.
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.
On OS X, Time Machine offers a simple set-once-and-forget backing solution that periodically backs up. One can simply hit Time Machine on a file/folder to view a history of automatically-saved versions, with preview, and restore as necessary.
I'm sure there are similar solutions on Lunix and Windoze.
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
Only Office has a document management and versisioning system built in. Plus for small offices, you'll get the additional features it provides. The community version (local install) may be the better choice for this scenario.
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
You can't herd cats. You need to get in there, explain to people how and why to version, and enforce it.
People who can't use it, train them more, some dogs need more reinforcement than others.
End of story.
Fuck fucking beta too.
I had to override my user agent to mobile AND switch to beta to give you (+1; Insightful). Modding was impossible with normal Beta.
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
Assuming they use Microsoft Office products. Get then to use Sharepoint online or shop around for someone that does Sharepoint hosting. If they know Microsoft already then it's the easiest system to get them to learn that automatically incorporates version control.
What's Beta?
Taking guns away from the 99% gives the 1% 100% of the power.
Use GIT, not Subversion. I found, much to my disturbance, that Subversion falls down with large projects and corrupts itself (SourceForge servers, no less.) GIT handles large projects with ease.
I do not fail; I succeed at finding out what does not work.
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?
This. Either use Google Docs or Sharepoint or whatever. There are also document management systems that run on the server side like Alfresco.
it's easy and affective.
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 think they should use git. My cousin currently is able to use it for his small business and if he is able to use it then I think they should be able to as well. Github has servers they can use to store their information and they can pay for the service.
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
There are specific applications to handle this sort of requirement. Take a look at Alfresco as an example.
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.
Do not use git: it is counter-intuitive.
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.
Beta is a sissy male who can't get a woman. See: timothy, samzenpus, etc.
Has versioning in built. Dump stuff there and you can go back to any version that you like. Done.
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.
Sharepoint or configure the Windows server to do shadow copies and keep versions.
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.
These two products will provide you with a set and forget system of endpoint backup and secure filesharing that won't make your end users crazy trying to figure out something new and is very simple to administer as well as being low impact on the network.
Is it a windows based network? If so, have their IT people turn on Shadow Volume Copies. Problem solved.
Same here, but most of my "middle of the road" friends are just confused and classify me as a "nut". The life of a libertarian is not easy.
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.
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.
I really don't know what you're on about. The formatting of http://slashdot.org/?nobeta=1 hasn't changed in a long time. That's been my bookmark since before the Slashcott; why isn't it yours?
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!
You don't say what kind of budget that you're looking to spend, but there are lots of commercial (i.e. proprietary) products that do exactly what you're looking for such as Worldox.
I imagine it is hard to be a corporate whore.
How many users, customers, branch locations, % of task to defined job, lost profit or costs. For small numbers of cost etc, user training, a few meetings on file naming and locations should do, large multiple locations would suggest database transactions and record locking. How much control do you need or want?
So what they need is an electronic document management system.
Alfresco does everything that they're looking for and more. Either pay for one of the commercial products or you can roll your own with the community version.
http://www.alfresco.com/
http://www.alfresco.com/community
Other posters have given several solutions, just collecting and adding my voice to a few of them:
in a pinch:
Google docs: lightweight and simple, with limited functionality and a light learning curve
Sharepoint: simple to use, full of hassle to administer, limited functionality, gets expensive
mediawiki: like sharepoint without the licensing problems, but gets limiting beyond simple document collections
More serious solutions:
Alfresco: serious document/object management and workflow, free version to start/pay for support if you like it (spinoff of Documentum)
Documentum: elder god #1 of doc management, excellent repository, workflow, project management functions. rather expensive
Opentext Livelink: elder god #2 of doc management, excellent repository, project management, nice Visio-like workflow development that makes sharepoint devs cry, also rather expensive.
TLDR:
Google docs if you need a fix today, Alfresco if you have a month or two to fix the problem and want it to stay fixed.
I think not...(*poof*)
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.
Has pretty good basic version control built in and also solves many other storage headaches into one solution.
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.
There's a whole industry that's devoted to this problem: Digital Asset Management. Files, organization, metadata, versioning, transcoding formats, proxies for viewing, workflow, etc, etc.
We deploy a virtualized Alfresco installation. ...
Webbased document management incl version control, tagging, checkout
Works perfect with LibreOffice.
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?
TagMyDoc aims to to be a kind of light-weight version control for "everyday" documents (like Word docs and Excel spreadsheets).
One of its goals is to disturb normal workflow as little as possible (not requiring too much training). But it will tell you immediately if a document is out of date.
http://tagmydoc.com
is the word you're looking for they're expensive bloated and tedious to use but its all the rage now and the solution to your problem.
sharepoint, alfresco, oracle makes on i cant remember the name of. others probably exist also.
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?
Microsoft is widely misunderstood. The purpose of Microsoft software is to do evil, and it does that very well. Viewed that way, Microsoft is a successful company.
My opinion, shared with many others.
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.
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.
This is a sure sign that you're wife's company is basically doing it wrong.
There have been enterprise content management applications on the market for a few decades. They solve the problem of managing your documents, with versions, and hierarchies.
If you're manually doing this stuff in shared folders ... your company is using outdated methods. Unless you're a really young company, or only have a handful of people, most companies have grown out of this literally years ago.
If your business people are doing their own version control, this is a huge business risk, and it will bite you in the ass one day.
Seriously, 1995 called, they want their document management back.
Lost at C:>. Found at C.
" 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
rcs and grep - they have both been around for 1000 years
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
This issue is being made way too complicated. Microsoft Windows Server has had excellent support for preserving up to 64 previous versions of files for a number of years, in the form of Volume Shadow Copy.
http://www.techotopia.com/index.php/Configuring_Volume_Shadow_Copy_on_Windows_Server_2008
Since "(your) 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" it makes sense to use Microsoft Sharepoint. With Microsoft Sharepoiint she and her co-workers can easily check-out a document, edit the document, check-in the document with the same name each time. In the event reverting to an older revision of the document is necessary she can click the appropriate link and the desired version appears on screen. There is absolutely no justification for a version control system such as Git, Perforce, SVN, et. al. for typical officer workers whose primary tools of information communication are Microsoft Office.
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?
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.
This is a classic case of when "computer people" are asked to solve business problems.
No. Don't use a software-development-oriented version control system with documents. That's like doing up a philips-head screw with a flat-blade driver. It'll kinda work, but there are far better tools for the task.
Documentum has been mentioned, as has Sharepoint. Bentley ProjectWise is another tool, that while geared towards CAD drawings, manages Office documents natively (e.g. indexes their contents, stores metadata, integrates with open/save dialogues, etc). These are document control tools, these are what your office people should be interacting with.
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.
Using the needs-lock attribute. People shouldn't have to ask everyone in the office if they're making changes before updating a file.
Also, people save as different names because they're afraid they may need the current version again. SVN should fix this problem, too.
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.
You seriously want a document management system, not source control. There are plenty of good ones out there, opensource closed source, "cheap", expensive whatever you fancy.
The two have some similar themes but are entirely different in the problems they solve and the way they are used.
A document management system generally would have a much simpler user interface which you most certainly want for a "general" user base, they are also generally based on pessimistic locking rather than optimistic locking as you probably don't want to do a merge if 2 or more people change the same document.
just use google docs
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.
If your job requires you to do things that you are unable to do, then you are unqualified. If you can't wrap your mind around the issues surrounding version control, then you shouldn't be responsible for any form of document management. The tools aren't the problem. Ignorance is the problem.
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.
I've tried getting non-programmers to use programmer style tools; subversion, perforce. Didn't work out.
I suggest enterprise document mgmt products such as Xerox ECM http://www.services.xerox.com/enterprise-content-management/enus.html
and possibly Alfresco, etc.
Looks like a file system, acts like a version-control system.
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).
Docs have revision history....why aren't they using that?
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.
There are electronic document management systems on the market that deal with just this problem. Search for EDRMS.
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.
I've implemented multiple doc control solutions for tech and nontech teams, and by far the biggest issue I run in to is that the teams do not have a consistent process or user training on the process. If another tool is added without first addressing those parts, its unlikely to make much improvement for the whole team. Here are some thoughts on a simple approach to getting them organized:
- Make it someone's job to define and communicate the doc control process. Depending on the number of files and users it may be a part or full time role. If mgmt won't support this, the situation is unlikely to improve.
- have the person inventory where files are and survey users about their doc issues,then present the findings to the team.
- create a one page doc control procedure that describes to minimum basic steps people are already taking, don't try to change too much too soon, just get the as is process in writing, then communicate the process to the team
- propose a simple change to the process, ( like asking users to save important docs in a file directory)... Communicate the proposed change, implement the proposed change then recommunicate that the change has happened.
- repeat incremental changes approach until you see that users are getting the value.
- one the value of doc control is firmly rooted, then major changes like new tools can be implemented with less risk of failure and push back.
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.
The easiest path is to add a tool like Dropbox, box.net and competitors into the mix. Users can continue to stick version, date and latest-editor attributes into the filenames if they must. In the mean time, you will have versioning, sharing, backup and undelete options automagically. Better than google docs because the files live on your local hard drives as well as in their cloud, so less risk if they go away. Security could be a concern but don't over-estimate the risk. I have seen great results with these simple tools in businesses with weak IT skills and support.
Clearly the most practical solution is to reimplement the office suite in-house to include built-in version control. I'm surprised nobody else has suggested this.
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!
It's opensource self-hostable Dropbox replacement, with basic version control, deduplication, and user-friendly clients for all major platforms. And it just works (unlike ownCloud and others).
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.
http://en.wikipedia.org/wiki/D...
Spouse's response: Honey, what is sloth-dot? and what in the world is p4?
"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