ALI AFSHAR: Hi, everybody.
Welcome to Google Developers Live.
My name's Ali, and today I'm going to be talking to you
about revisions in the Google Drive API and revisions, in
general, in Google Drive.
So firstly, what is a revision?
Well, every time you change a file in Google Drive, it is
snapshotted, and the previous files are saved.
So this way, you have a very good Undo history that goes
back for a long, long period of time.
This is not an alien concept to you if you're a developer.
This is exactly how version control systems work.
And if you used CVS back in the day and Subversion since
then, and much more recently Git and Mercurial and these
nicer tools like this, Google Drive has this built in, OK?
So anything you can do in Google Drive, you can also do
with a Google Drive API.
And that's why we have full revision management there.
So when you upload a file, if it's been updated or if you
just modified some of the metadata, you can pass the
flag to make sure that a new revision is created.
Or you can say, no, I don't want a new revision created,
and the last revision remains as the current one.
So really, really useful.
It means you won't lose your history.
Now, along with the revisions come a few
extra little features.
So each revision is saved against a file.
So you can say, give me all the revisions for this file.
Now, each of those revisions also can be downloaded.
You can view the metadata.
You can export them if they're a Google Doc.
So each of these revisions behaves almost like a file
resource does in the API.
So when normally you would get a file or export a file or
download a file, with a revision, you can do them for
each of the revisions of that file, so that's really, really
useful and essentially a version control system.
So that's the first part--
downloading and grabbing metadata from
the individual revisions.
Another part of this is publishing revisions.
Now, we have a feature where you can actually say, I want
this revision of a file to be published to the world, OK?
Now, you do that by setting the published property, and
obviously that's a Boolean.
You set it to "publish true/false." If a revision has
been published, then a new field appears there, and that
is the published link field.
And that gives you a link to a URL, which you can give that
to people to publish.
So you can say, I want to publish, say, revision number
three of a file.
Now, when you create revision number four, four will not be
automatically published unless you publish it or unless you
set a flag called "publish auto," which means publish the
most recent revision, whatever it is.
That's really useful, because if you think about the normal
workflow of creating content to go online or within your
company intranet or whatever, usually you want to create the
latest revision, have a round of reviews, maybe go over it
yourself, maybe think about it for a while, and then publish.
So the publish step usually comes after the content
creation step.
So that would be a workflow here.
And again, the API is there to help you.
Create the file, publish one revision, modify it.
When you're happy with it, publish the next
revision, and so on.
So essentially, that is all there is to revisions.
Just to recap, a revision is kind of like a file, but each
time you save a file, each time you modify file, a new
revision is created.
These are stored, and you can grab them one by one and
download their content or look at their title, whatever you
want to do.
Additionally, we have publishing functionality.
So you can publish a revision, you can automatically publish
the latest revision, and you can keep revisions
unpublished.
So thanks very much.
That was a very short introduction.
There's not much to it there.
If you need the feature, you will use it.
Just to go on, there is also--
yep, a question on YouTube.
This is a great one-- "turning Google Drive into Subversion.
I guess I do care." So I guess they're saying, can I turn a
Subversion history into a Google Drive history?
Yeah, you can, actually.
Why not?
And vice versa.
So to go from Google Drive to Subversion, what you would do
is you would find the file you want or find all the files you
want, but you'd have to individually
on a per-file basis.
That's really the difference here.
Subversion is a repository-based thing.
Google Drive is a file-based thing.
So you would get the file.
You would download the first revision, copy it into your
Subversion repository, and commit it there, download the
next revision, commit it there, and you would build the
mapping like that.
And you could store the revision idea against
Subversion's revision ID.
And you could store them somewhere in the database or
something, or a file.
And that would work for you.
To go in the opposite direction, you would check out
a specific Subversion revision.
I can't even remember how to do that.
It's been a long time since, but it's probably like minus R
and then the revision number.
Then you would check that out into a local file.
Then you would upload that file if it's the first one.
Subsequent checkouts, you would then update the file,
causing a new revision to be created.
And again, while you're doing it, I would
probably save the metadata.
So yes, it's not quite the same as Subversion.
You wouldn't really use it to manage source code because of
the non-repository style nature.
But it's very similar functionality, and you could
easily create a mapping between the two of them.
So that's Subversion.
These days, people don't really use that too much.
So thanks very much for watching.
If you have any questions, please ask them on Stack
Overflow, or get in touch on Google+.
Thank you very much.
Bye-bye.
[MUSIC PLAYING]