Ask Slashdot: Version Control For Non-Developers? 343
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.
perforce (Score:2, Informative)
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.
Re: (Score:3)
My preference would be Google Drive or Dropbox
This can help (Score:5, Informative)
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.
Re: (Score:3, Informative)
doesn't solve concurrent edits = you have no single source of information = you can't just pick the last.
i don't think their problem is solvable just with tools. they need to understand collaborative workflow: you either block or are prepared to merge often. i don't know of any such tool that doesn't require a minimum of training and thought. i've heard microsoft claims to have such thing in office 365. and i wouldn't recommend ms to my worst enemy but since it looks like they are on the hook anyway they ma
Re:This can help (Score:4, Insightful)
...another radical alternative is google docs. yes, sheesh, but better than office.
My fear is that Google docs has attained the level of usability and popularity that often precedes a Google project, service, or feature being shut down...
Re: (Score:3, Insightful)
This is a terrible idea.
a) in practice people will make typos on the 14 char datetime string, miss leading zeroes etc.. resulting in a mess of similarly named files in the folder
b) even if miraculously this format was followed rigorously by the users for every file, you'd still have people forgetting to sort the directory files by time (or thinking it is sorted when it isn't) and opening the wrong file etc
Timestamping files with a 14 char string is the kind of thing computers are good at and people are not.
Re: (Score:2)
Neither of which is a version control system.
Dropbox definitely offers version control.
I thought Google Drive did, but may be wrong; maybe it's just Google Docs that does version control?
Re: (Score:3)
I thought Google Drive did, but may be wrong; maybe it's just Google Docs that does version control?
Google Drive sort of offers version control for non-Google-docs. Previous versions are merely saved (which you can argue is not really version control, I suppose). However --- be careful --- they are only saved for 30 days unless you actively go in and retain them. I lost 7,000 words of a novel I was writing partly because I didn't realize this (and admittedly, partly because I overwrote the working copy).
A Google Doc has much better version control.
Re: (Score:3)
If you actually use Microsoft Office with their collaborative tools enabled (aka saving to OneDrive or SharePoint server) it's much much better than Google Docs. The problem is that people use Microsoft office often in the worst possible configuration and insist that their Office 2003 version "has everything they would ever need" with everything turned off and then complain that it's not as good as Google Docs. Yes, if you use Microsoft Office from the year 2000 and don't use any of the collaborative fea
Re:perforce (Score:4, Insightful)
LOL. I was going to say Perforce too. But as a joke!
I'm sure these teachers will love the process for creating "changesets" before they can check in any documents. Perforce is awesome, but not really for laymen.
Re: (Score:2)
Right, and merging word documents is going to work really well too >.
Re: (Score:3)
Ooops. I misread the OP and thought he mentioned teachers. Anyway, I think the idea applies the same to business users. A technical tool is going to only really work well for technical staff. There are tools like Google Docs that offer versioning built-in without thinking about it. Even MS Office has it available too. But in any scenario, user training is going to be needed to make people understand these features and how to use them. In that case, even something as simple as a naming convention that uses t
Re: (Score:3)
> Perforce is widely used in the video game industry for saving both code AND art assets.
Actually Perforce's popularity is slowly decreasing due to free version control for code:
* Git,
* Mercurial, or
* SVN
At our fortune 50 company we use SVN (SmartSVN on OSX, TortoiseSVN on Windows)
For binary assets, AlienBrain is pretty popular. I've used it in the past and it seemed decent.
http://gamedev.stackexchange.c... [stackexchange.com]
Re:perforce (Score:4, Informative)
As someone who trained people on my team in the video game industry in how to use Perforce who were already familiar with version control concepts, I would reiterate that I don't see any of the above as viable solutions for this bloke. It's exactly the point that all of these tools are going to require non-trivial training, and do you think this guy is going to be able to tell his wife... "Hey! I asked Slashdot, and they recommended Perforce (or git or SVN or CVS or VCS or PVCS or whatever!), so just teach that to your colleagues and you're all set!"
No. What they can perhaps nominally hope for is to get everyone to switch to Google Docs which does version control and concurrent editing and merging without you asking. Heck even the built-in MS Office does versioning, but again, that is going to require team training and buy-in. Meh
To reiterate, I like Perforce a lot and found the reward for spending the time to understand its core concepts worthwhile, but its learning curve is steeper than other tools out there. And if git ever got decent GUI tools, it would beat its pants off.
Re: (Score:2)
Aside from Perforce itself, non-developers should look into Perforce Commons, a web-based frontend to document storage. It's all drag-and-droppy and pretty and has search and etc. etc. It's a good solution if the organization is paranoid about having all their documents in the cloud.
If they're not paranoid about that, why not Dropbox or something similar? They have their desktop apps so non-developers won't have to be confused about web interfaces and whatnot.
Please downvote anyone that says 'SharePoint'.
Re: (Score:2)
perforce - 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.
Used at a workplace, many years ago, for non-source code (binary file format)-versioning needs (e.g. documentation, when that was still written as part of the process, which goes to show how long ago that was). Anyhow, we didn't particularly like it, and soon started talking about "Perverse"....
I'm PRETTY SURE it has improved since those days...
Re:perforce (Score:4, Informative)
Re: (Score:3)
That functionality belongs in the revision control system, not hidden away in some app someplace.
Re: (Score:3)
All the more reason not to use opaque binary formats at all.
Re: (Score:3)
The entire videogame industry stores source code, art assets, and documents in source control repositories, and it's absolutely indispensable to them.
When some people talk about how binaries shouldn't be stored in source control, many mistakenly believe that refers to all binary formats. In truth, what is often meant by this is that binary executables created from the source that's being stored shouldn't be in the repository as well, since it can obviously be generated from the source itself.
Binary documen
Business problem != technology problem (Score:5, Insightful)
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.
Business problem != technology problem (Score:5, Insightful)
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.
Re:Business problem != technology problem (Score:5, Informative)
Seconded. It's also easier (in my experience) to get non-tech people to understand a naming standard than it is to get them to learn a new app.
You do NOT want to be the one who has to help everyone find their "lost" documents that NEED TO BE SENT RIGHT NOW IT IS A CRISIS WE WILL LOSE THIS ACCOUNT AND IT WILL BE YOUR PROBLEM OF COURSE I CHECKED IT IN YOUR APP LOST THEM.
Re: (Score:3)
And as a last ditch effort I would also firewall the problem by enabling Shadow Copy of the file server (assuming they have a Windows Server). Then when someone inevitably does write over an existing document, fail to use the right file name convention or use Office "incorrectly" there'll still be the old version in the Versions tab of explorer.
They could also setup a OneDrive account and that would avoid using Sharepoint. And all you would have to tell them is "save to OneDrive" and you would get collabor
Re: (Score:3)
People still mess up naming schemes and will still blame "you" when they can't find their documents. Then, when you point out that they failed to follow the corporate document naming standard, they will blame you for the naming standard.
Basic versioning: Notepad++ (Score:3)
The free Notepad++ [notepad-plus-plus.org] can make a backup of every save, with date and time in the
Re: (Score:3)
> MS Office has some pretty good versioning support
This is the same company that bought SourceSafe [wikipedia.org] from another company and you want to _trust_ them NOT to screw up version control???
There is this table [wikipedia.org] of collaborative software. SharePoint's last stable release was in 2010, almost 5 years ago. Again, you want to trust Microsoft with updated Service Packs and Cumulative Updates ??
Pick an easy solution (Score:5, Interesting)
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.
Pick an easy solution (Score:2)
This. Either use Google Docs or Sharepoint or whatever. There are also document management systems that run on the server side like Alfresco.
Re: (Score:2)
Sharepoint online is available to non-profit companies for a low fee
Document libraries are pretty easy to use and apply their own versioning
Re: (Score:2)
Re: (Score:2)
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.
The big downside is that the Google Docs UI is dramatically different from Word/Excel/etc. If they need more than just a place to throw text and actual layout work is being done, the users will need to retrain on the Google Docs way of getting things done. It's not impossible, but it's also not easy either.
Re: (Score:2)
The big downside is that the Google Docs UI is dramatically different from Word/Excel/etc.
Change 'downside' to 'upside'. I'd rather work with Google Docs any day. Yes, there may be a little retraining. Yes, Google Docs is missing features that you very likely don't need and are just time wasters. The only real downside I've found is that it's slow with very large documents.
Re:Pick an easy solution (Score:4, Insightful)
Some businesses are not comfortable putting their documents in the hands of another party due to security concerns. Some also are hesitant to rely on a service that may go away with relatively short notice.
Google Docs would require additional training as well if they are already using Word/Excel and legacy documents would need to be maintained somewhere.
Google Docs does not import a lot of Word and Excel documents adequately. I've rarely had it import a Word document with sufficient fidelity that I didn't find it necessary to at least touch it up. With Excel documents, I almost always have to do a lot more than "touch up" work to make it whole again. Therefore, it's likely switching to Google Docs would require a lot of effort if some of these documents are "living" documents that change from time to time.
Re: (Score:2)
Throwing more technology on the pile won't help without a lot of user education
Yes, and it will be difficult to educate non-technical users on version control, even if they all agree it is the right solution (they won't). Also, version control doesn't work that well for binary formats. Could they use something like Google Docs, where sharing and versioning are transparently built in to the basic functionality?
Re: (Score:2)
It is built into SharePoint / Office the same way if everything is configured right.
Re: (Score:2)
Re: (Score:2)
I only disagree in that, version control just isn't that hard and doesn't take that much education to get started with. A lot of the problem really is more about it looking intimidating with a couple of new terms people need to get used to. I could show a person how to use git as a normal user in about 5 minutes.
Couple it with a system like maven and who needs sharepoint? Sure its a bit more setup work for the admin but, its very flexible and easy to use.
Re: (Score:3)
Throwing more technology on the pile won't help without a lot of user education, and if you had that you would not need the technology anyway...
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.
This. SharePoint does it in a fairly elegant and comprehensive way if you are a Microsoft shop. If you don't want to invest the time into installing/learning SharePoint, just look into Shadow copy or one of the many delete-less for the server, so you can go back in time if changes do get clobbered. For a more user-friendly but less controllable solution, every cloud file storage platform (Onedrive, google drive, dropbox, box, etc) offers this feature in a pretty straightforward way, and they have all hav
Re: (Score:3)
SharePoint is the worst possible answer (without extensive user training). It proves it's physically possible to suck and blow at the same time.
The problem is, while there is built-in change tracking for editing a document, it's easier for the user to just upload a new version of the doc, instead of editing the existing doc, which ruins everything - it relaces the existing doc and all editing history.
Maybe it's possible to configure SharePoint to make the wrong thing impossible, but I've sure never seen in
Re:Business problem != technology problem (Score:4, Interesting)
Throwing more technology on the pile won't help without a lot of user education, and if you had that you would not need the technology anyway...
1) Create a rational naming convention and use that.
Go no further than this. I've worked in office environments where we had dozens of editors and sub-editors proofing and editing tens of thousands of legal documents (legislation, judicial decisions and regulation), where even a single character out of place was unacceptable. After years of trial and error, the single most foolproof way of working with these documents was using the file system to define where they were in the editing process, and using filenames to indicate their status and ownership.
It's primitively simple. But simple is an abundantly good thing in this context. Make some basic rules. Enforce them. Bob's your uncle.
Re: (Score:3)
use Sharepoint's (base version is free beer)
The base version Sharepoint is not free, it is included in the Windows Server license you need to buy. And don't forget the SQL Server Licence.
Re: (Score:3)
Actually you can do diffing of MS Office docs via SharePoint. Makes picking out when people try to ninja requirement changes into a spec super easy to see ;)
There are horrible, horrible things people try to do in SharePoint, but storage/organization, versioning, and collaboration of MS Office documents is actually something it does really, really well.
-Rick
Take a look at Owl (Score:4, Interesting)
http://www.doxbox.ca/ [doxbox.ca]
It is a document management system
Document Management System (Score:2, Informative)
Something like Alfresco ?
Re: (Score:3)
Alfresco is much more serious than what's he asking for. That's a step up from SharePoint. A typical use case would be: company X wants legal to be able to access documents by different dimensions than how they were generated...
Document Management System (Score:5, Insightful)
Re: (Score:2)
I'll second a document management. We use Opentext Content Server.
Works well for us - plugins provide seemless use from MS Office.
Re: (Score:2)
Re: (Score:3)
As a librarian's husband, I feel a bit of a duty to point out that a larger company (say, of the size where document control and user training are becoming real problems) may be well-served by hiring a corporate librarian.
Librarians are trained to organize documents and articles in an appropriate manner, and to help users find what they need quickly. Categorization and cataloging should not be left to the whims of the users.
Re: (Score:3)
As a librarian's husband, I feel a bit of a duty to point out that a larger company (say, of the size where document control and user training are becoming real problems) may be well-served by hiring a corporate librarian.
One moment while I laugh myself sick. Sorry, you're not wrong it's just that doing something sensible like hiring an expert and then listening to their advice is pretty rare these days.
Documentum or similar (Score:2)
DON'T use git.... (Score:2, Informative)
I'd avoid Subversion (Score:3, Informative)
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.
Re:I'd avoid Subversion (Score:5, Informative)
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.
TortoiseSVN already does this. It uses the hooks in Office to create what is basically a "track-changes" copy, where previous version is the base, and new version is if you accept all changes. This is about as good as it gets to diffing Word files, and flows logically with how they were intended to be used in businesses anyway. It will do the same for Excel, but it's... a monster that should never be allowed to live.
Re:I'd avoid Subversion (Score:4, Interesting)
Re: (Score:2)
Subversion can lock files in order to avoid merging binary files
My experience (Score:2, Interesting)
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
Google Drive / Docs (Score:2)
Github have their own windows client now (Score:2)
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
OpenVMS (Score:4, Funny)
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 (Score:3, Informative)
Alfresco has a versioning capability: http://docs.alfresco.com/4.0/concepts/versioning.html
Use specialized tools designed for this (Score:2)
If you can't afford to pay for a real solution, you should be prepared to invest an exceptional amount of time in a cust
Don't forget the people side of the equation (Score:5, Insightful)
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.
Proper solution (Score:2)
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
Proper solution (Score:3)
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
Document Version Control (Score:5, Informative)
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.
Sharepoint? (Score:2)
or confluence, alfresco.. or most other CMSs.
You are asking the wrong queston... (Score:5, Insightful)
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...
Re: (Score:2)
Re: (Score:2)
So you are suggesting they depart form Office and use some other tools?
Where I see what you are suggesting would work, I'm pretty sure the costs incurred in the implementation of such a solution is going to be way up there and unless you have carefully considered the business needs and designed the process and trained the team in both the process and the tools you will put this place out of business.
I've seen things like this happen. I saw a catering company that worked just fine on paper, they had an or
Re: (Score:2)
You simply have to solve the multiple editors problem to avoid the nasty merge problem. Unfortunately, not avoiding the merge when possible IS a process problem. Fixing the process doesn't take tools, it takes a bit of thought followed by communicating the new process to the team.
Until they solve the multiple editors problem, all the configuration management in the world won't help them. However, if they fix the process problem, any of the common configuration management tools would work just fine.
Furthe
Re: (Score:3)
You must not write software.... The Evils of MERGING cannot be over estimated. Us software engineers go to great lengths to avoid having to do a difficult merge process because it is error prone, time consuming and messy...
If you don't design your process to avoid the merge, you will be forever doomed to spend your resources trying to do merges.
Tools *can* help you, but only if the process model of the tool matches your process close enough. But good tools usually cost lots of money, even the free ones,
SVN works for this (Score:2)
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.
Microsoft SharePoint (Score:4, Informative)
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.
uh yea (Score:2, Interesting)
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.
OpenText does that (Score:3)
http://www.opentext.com/what-w... [opentext.com]
Disclaimer: my cousin works there.
I used this and it works. (Score:5, Interesting)
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.
methodology (Score:3)
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.
SharePoint (Score:3)
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?
MediaWiki. (Score:5, Interesting)
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
3 Easy options (Score:3)
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.
Been there, done that. Here's how: (Score:5, Interesting)
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
Training (Score:3)
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.
Re: (Score:2)
A lot of us are on soylent news. http://soylentnews.org/ [soylentnews.org]
Buck Feta!
Re: (Score:2)
Re: (Score:2)
GIT also does checkouts/checkins a lot faster than Subversion. Usually 30-40 seconds vs. 20 minutes or more for Subversion.
Re: (Score:2)
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.
Re:Use GIT (Score:4, Interesting)
Re: (Score:2)
Re:Use GIT (Score:5, Informative)
Re: (Score:2)
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.
Re:Use GIT (Score:4, Insightful)
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.
Re:Use GIT (Score:5, Interesting)
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.
Re:Use GIT (Score:4, Interesting)
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.)
Re:Use GIT (Score:4, Interesting)
DO NOT Use GIT (Score:2, Interesting)
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.
Re:DO NOT Use GIT (Score:5, Interesting)
With SubVersion, you can check out subtrees instead of the whole repository (even non-recursively, so you can check out a directory "in the middle"). That's something that Git or Mercurial can't do by design; IIRC it's because the always-complete-repository approach makes merging and other tasks much, much easier. In your SVN working copy, only the data of commit you've checked out are stored. For everything else SVN needs to contact the server which depending on the requirements and workflow, is either a good or bad thing. On the other hand, Git and Mercurial do have the complete history locally which allows them to perform a lot of tasks without contacting a server that SubVersion could not do (simple example: get log history of a file).
But it's actually besides the point: all of these things won't matter to an office user. Ease-of-use and chances-to-screw-up do.
Re: (Score:2)
Re:Backup? (Score:5, Informative)