Hi all,
I have a technical question that isn't really medieval. I run several journals out of the Lethbridge Journal Incubator (you can learn more about the model here: http://journalincubator.org/). Until now, we've used Subversion as our central cloud storage. This year, however, I had a complete turnover in the graduate assistants, most of whom were not very technically inclined and I'm finding Subversion is more hassle than it is worth (it mostly works well, but if something goes wrong, the students can't fix it).
What we need is a cloud based repository system, preferably one that allows us access to arbitrary revisions (students find it comforting to know they can always correct mistaken overwrites), and preferably does version control of some kind--either locking or svn-type comparison. Best, however, would be something very low maintenance, drag and drop, and preferably doesn't require the use of a special client for file manipulation (that's where our subversion issues come).
I'm thinking Dropbox or Drive, though I don't know anything about setting those up for an organisation. Does anybody have any other tips?
-dan
Easy answer is Github. If your assistants do not have very technical skills and are uncomfortable with a terminal, it's very easy to use from their downloadable UI for both Mac and Windows.
https://mac.github.com/ https://windows.github.com/
On Monday, December 29, 2014, Daniel O'Donnell daniel.odonnell@uleth.ca wrote:
A question I'd have is how easy is it for github to cock up?
Subversion works great for us until a student does something unexpected. Then we end up having to go in and clean out all the locks and the like. That's the bit that is causing us trouble. It happens probably twice a year and leaves them all very nervous in the meantime. They aren't confident enough to google solutions and fix them themselves. So we have good interface with subversion via Oxygen; but it occasionally throws an error that sends everybody scrambling.
My fear is that Github would do the same: I'm willing to sacrifice version control for something consumer friendly.
On 14-12-29 03:38 PM, Abdullah Alger wrote:
Well, Github doesn't cause problems, it's really the user who messes it up.
However, if you get the idea of doing work on branches, then it is easy to delete a branch, or reset a branch if it's not pushed to the master branch. This might be a little confusing, but it's pretty easy to follow once you've done it a few times. As long as people are working on different branches and not messing with the master branch, then you should be fine. If they mess up their own branches, then there are ways they can move back to previous versions, or pull in the master again to their own project.
That's basically how Git works. As long as students cannot push to the master branch, you should be fine. They can always fork the main project and make pull requests to add to the master branch, which could be set up so that each commit (or modified file) to the master has to be approved. That way you always know what's being added to the master. Once a commit has been added to the master, then they are able to pull the new material into their projects so everyone is up to date.
I hope I didn't make this too confusing.
On Tue, Dec 30, 2014 at 1:09 AM, Daniel O'Donnell daniel.odonnell@uleth.ca wrote:
Maybe I should reask it. Is there a reason for not just using dropbox or drive?
I ask this not to disparage the advice for github, but because when I switch, I need something that really eliminates this problem (that is to say: be easily trainable to skittish people) rather something than replaces it with something else. I don't mean eliminating it in my research projects; only a project where there is a lot of turnover and people who need only brief access.
On 14-12-29 05:39 PM, Abdullah Alger wrote:
Answering in a completely different way, it may not be a choice between them. Ifttt should let you write a trigger that commits Dropbox or drive files to GitHub. That way your users see Dropbox and your backend sees GitHub.
Cheers Stuart
On Tuesday, December 30, 2014, Daniel O'Donnell daniel.odonnell@uleth.ca wrote:
This sounds like music. Ifttt?
On 14-12-29 09:39 PM, Stuart A. Yeates wrote:
https://ifttt.com/ - IF This Then That. It's a tool for getting APIable or RSSable websites to work together.
There isn't a recipe that does this exact thing, but there are a bunch of ones that do similar things: https://ifttt.com/recipes/search?q=dropbox https://ifttt.com/recipes/search?q=github
cheers stuart -- ...let us be heard from red core to black sky
On Tue, Dec 30, 2014 at 5:49 PM, Daniel O'Donnell daniel.odonnell@uleth.ca wrote:
If you're going to have high turnover, and you're still hesitant about using Git for version control, then I'd probably stick with something like Google Drive because the learning curve is almost zero. I don't think I'd go with Dropbox because is basically a file repository and you'd have to look at the dates when files are modified to see if changes have been made. Can you view the changes that were made to a file in Dropbox? I don't know. In Google Drive you can see the changes, but is it good for code projects? Not really. Have people written entire XML projects or any kind of code in a Word doc? Yes, but it's not good practice. I haven't seen projects that involved code using Dropbox or Google Drive because there are no mechanisms in place to stop bad code from entering the system. That's why most programmers use Git and that's why version control is not simply an exercise in tracking the dates when changes were made. It's inevitable that people will write bad code, but using a system that will allow you to accept or reject changes is better than putting code into the system then throwing your hands in the air when something goes wrong. Git shows you the changes and allows for moderation before connecting it to the master code.
I'd have to disagree with the comment that Git has a problem because it does not work with users' expectations and/or is too complicated. I learned it in a couple days. Just take a course on Code School for free. Millions of programmers use Git and Github daily without problems. You just have to follow certain steps in order to preserve good code and not push potentially problematic code into your system.
Saying that, if your students are working on digital humanities projects and are coding, they should learn Git. It's an essential tool that professionals use every day.
On Tuesday, December 30, 2014, Stuart A. Yeates syeates@gmail.com wrote:
On 12/30/2014 11:30 AM, Abdullah Alger wrote:
I was traveling all day and thus the recommendations I would've made have already been made by other people, but I cannot pass up the opportunity to second this, very strongly. Properly implemented, git can be extremely user friendly to use (my DMNES project linked in my sig involves a lot of data entry and requires scrupulous version controlling; my editors have a web-front end that they use and beyond creating an account on github, they never interact with git at all), and there is a large amount of documentation and help out there for those who are willing to put in a little bit (i.e., an afternoon) of time into learning it. Learning how to use git should be considered a requirement of someone who intends to work in digital humanities, just as learning LaTeX is one for anyone working in math or logic.
-Sara
+1 to what Abdullah and Sara have said about git and Github. If your student workers have any interest in this sort of work outside of the job itself then any time they may spend to become comfortable with these powerful tools will not be wasted.
That said, as noted, Dropbox does offer access to file version history and restoration of deleted files and folders, so that might be enough for your purposes. In my experience it often doesn’t handle simultaneous users of shared files very elegantly, so there is need for caution if that will be a common scenario. Google Drive is much better in this regard, but it’s not as flexible with respect to file types.
Josh
-- Joshua A. Westgard, MLS, PhD Systems Librarian Digital Systems and Stewardship Division University of Maryland Libraries College Park, MD 20742-7011 301-405-9136 (office) westgard@umd.edu
On Dec 30, 2014, at 15:52 PM, Sara L. Uckelman s.l.uckelman@durham.ac.uk wrote:
Th context here is a little different in that the students are not necessarily DH students, though the programme is funded because it teaches digital (and publishing) skills to HSS students. So we have to balance ease and interest with our mandate.
-- Sent from my phone using swipe typographical error production technology.
Daniel Paul O'Donnell Department of English University of Lethbridge
-------- Original message -------- From: "Sara L. Uckelman" s.l.uckelman@durham.ac.uk Date: 2014-12-30 13:52 (GMT-07:00) To: "dm-l, MailList" dm-l@uleth.ca Subject: Re: [dm-l] [Technical]: Suggestions for a replacement for Subversion?
On 12/30/2014 11:30 AM, Abdullah Alger wrote:
I was traveling all day and thus the recommendations I would've made have already been made by other people, but I cannot pass up the opportunity to second this, very strongly. Properly implemented, git can be extremely user friendly to use (my DMNES project linked in my sig involves a lot of data entry and requires scrupulous version controlling; my editors have a web-front end that they use and beyond creating an account on github, they never interact with git at all), and there is a large amount of documentation and help out there for those who are willing to put in a little bit (i.e., an afternoon) of time into learning it. Learning how to use git should be considered a requirement of someone who intends to work in digital humanities, just as learning LaTeX is one for anyone working in math or logic.
-Sara
-- Dr. Sara L. Uckelman Department of Philosophy Durham University https://www.dur.ac.uk/philosophy/staff/?id=12928 http://dmnes.wordpress.com/
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gid=49320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Quote/Cytat - "Sara L. Uckelman" s.l.uckelman@durham.ac.uk (Tue 30 Dec 2014 09:52:11 PM CET):
Why just git? I'm quite happy with mercurial (and BitBucket.org, cf. e.g. https://bitbucket.org/jsbien/ndt/wiki/wyniki). This was not my own decision, but practically all my collaborators preferred mercurial over other version control systems, so I joined them. There is at least one multiplatform GUI (TortoiseHg).
Best regards and Happy New Year
Janusz
Project and individual preferences are pretty much what drives us to use various version control systems. Mercurial and Git are similar, but I prefer Git because I use it daily and the people I collaborate with use it. I've seen companies use both systems, and Google has built their own internal version control system in addition to using Git for open source projects. The point I was trying to make was to use a version control system that works well for code. I don't think it matters which one, but as long as there is one that does a good job, that's what matters. Whether you use Git or Mercurial shouldn't matter. They are both better than Dropbox or Google Drive for code.
However, I think that Dan was just asking about using something that is easy to use with a high turnover of students. I'd suggest using Google Drive because you can modify and store all of your documents online and will be able to do everything in the browser.
On Wed, Dec 31, 2014 at 9:43 AM, Janusz S. Bien jsbien@mimuw.edu.pl wrote:
Quote/Cytat - Abdullah Alger abdullahalger@gmail.com (Wed 31 Dec 2014 11:01:56 AM CET):
Agreed. "The best tool is the tool you know best." (author unknown).
They are both better than Dropbox or Google Drive for code.
But what is "code"? Any text files can be considered "code" for this purpose if it is important for you to document and monitor changes.
Best regards
Janusz
Dear Daniel,
I am not sure if this is the kind of input you'd like, but I use Google Drive and Google Docs with teams frequently. They have proven to be invaluable tools. I am not sure what software you are using to edit your documents, but Google Docs records history of every single change and you can switch between "Edit" and "Suggest Edit" mode, the latter is extremely useful with multiple editor. I am not sure if Drive, just as a file share, will version documents for you. One aspect of Drive that doesn't work well at all is "Offline" mode. I have often 'pinned' a document to my device before embarking on a long flight only to find, when I attempt to open the document, an error stating, "no valid internet connection." Drives me crazy.
Anyway, my 2c.
Troy
On 12/29/2014 09:29 PM, Daniel O'Donnell wrote:
That's a good point. I use drive all the time too for teams and indeed was just using version control this evening with my son. Now we're talking about XML files and original word files (for the most part) rather than google docs. Can you use drive as just a dump?
On 14-12-29 09:49 PM, Troy A. Griffitts wrote:
Dan:
It sounds like Dropbox will work just fine for your purposes, provided all that you are looking for is recovery from the save points of the entire file and not specific nodes. In my view, if users can cock up Github then the problem is with Github and not the users (an application should conform to user expectations and not the other way around). I like all the services that Github provides but its complexity and the requisite learning curve might turn it into an obstacle for your user group (expecially if you expect regular turnover). And, you can expand your cloud size by recommending all your staff for a dropbox account. I've done that on a regular basis and right now I have over 52GB of space more than enough for document handling. Or you can go for a commerical account as they have a pretty affordable sliding scale of cost.
I've used Projectlocker as an SVN, since it has a good user interface, but again it might be more than what you need.
Jim
On Mon, Dec 29, 2014 at 11:29 PM, Daniel O'Donnell <daniel.odonnell@uleth.ca
wrote: