1 files changed, 163 insertions, 0 deletions
diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt
new file mode 100644
index 0000000..3c6eba4
--- /dev/null
+++ b/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt
@@ -0,0 +1,163 @@
+1
+00:00:00,160 --> 00:00:01,970
+Something else I want to mention is that there
+
+2
+00:00:01,970 --> 00:00:05,460
+are many different version control systems but we can classify
+
+3
+00:00:05,460 --> 00:00:09,250
+them normally in two main types: centralized VCS's and
+
+4
+00:00:09,250 --> 00:00:13,230
+decentralized VCS's. So what is the difference between these two?
+
+5
+00:00:13,230 --> 00:00:16,750
+Let's use again our friends Janet and Brett.
+
+6
+00:00:16,750 --> 00:00:19,510
+In the case of a centralized version control system
+
+7
+00:00:19,510 --> 00:00:22,290
+there is a single centralized, as the name says,
+
+8
+00:00:22,290 --> 00:00:25,230
+repository. On which they are commiting their files. So when
+
+9
+00:00:25,230 --> 00:00:27,290
+Janet commits a file. The file will go from
+
+10
+00:00:27,290 --> 00:00:30,390
+her local working directory to the repository, and the same
+
+11
+00:00:30,390 --> 00:00:33,520
+will happen to Brett. The decentralized system is a little
+
+12
+00:00:33,520 --> 00:00:37,310
+more interesting because in this case, they will both have
+
+13
+00:00:37,310 --> 00:00:40,790
+sort of a local repository in which they can commit
+
+14
+00:00:40,790 --> 00:00:43,970
+their changes. So they can commit changes without the other
+
+15
+00:00:43,970 --> 00:00:47,940
+users of the VCS being able to see these changes.
+
+16
+00:00:47,940 --> 00:00:50,300
+And when they're happy with the version. And when they're
+
+17
+00:00:50,300 --> 00:00:53,900
+ready to release the version, they can push it to a central
+
+18
+00:00:53,900 --> 00:00:56,840
+repository. And at that point, it will become available to the other
+
+19
+00:00:56,840 --> 00:01:01,100
+users of the repository. To the other users of the VCS. There
+
+20
+00:01:01,100 --> 00:01:02,870
+are several advantages in a distributive
+
+21
+00:01:02,870 --> 00:01:04,300
+system. I'm just going to mention a few,
+
+22
+00:01:04,300 --> 00:01:07,520
+because there are really many. One is the fact of having this
+
+23
+00:01:07,520 --> 00:01:10,570
+local version. If you used VCS before, I'm sure you've been in
+
+24
+00:01:10,570 --> 00:01:13,280
+the situation in which you want to kind of take a snapshot
+
+25
+00:01:13,280 --> 00:01:15,820
+of what you have. But you don't want that snapshot to be available
+
+26
+00:01:15,820 --> 00:01:18,200
+to the other users. Because it's still not ready to be
+
+27
+00:01:18,200 --> 00:01:21,240
+released, to be looked up. If you're using a centralized system,
+
+28
+00:01:21,240 --> 00:01:23,140
+there's really no way you can do that, unless you make
+
+29
+00:01:23,140 --> 00:01:25,150
+a local copy, which is something we said you don't want
+
+30
+00:01:25,150 --> 00:01:28,625
+to do. With a distributor, with a decentralized VCS you can
+
+31
+00:01:28,625 --> 00:01:32,444
+commit your local changes here, in your local repository, and you
+
+32
+00:01:32,444 --> 00:01:37,030
+can push them to the central repository only when you're ready.
+
+33
+00:01:37,030 --> 00:01:40,870
+Another big advantage, is that you can use multiple remote repository.
+
+34
+00:01:40,870 --> 00:01:43,210
+In fact, centralized is not the right name for this
+
+35
+00:01:43,210 --> 00:01:45,980
+one. This is just a remote repository, and I can have
+
+36
+00:01:45,980 --> 00:01:48,910
+more than one. For example, Brad might want to push
+
+37
+00:01:48,910 --> 00:01:52,150
+to another remote repository. As well. For instance, this could be
+
+38
+00:01:52,150 --> 00:01:55,940
+a repository where the files are accessible for wider distribution.
+
+39
+00:01:55,940 --> 00:01:59,620
+Imagine developing a software system in which a team is sharing
+
+40
+00:01:59,620 --> 00:02:02,930
+internal versions, and then only some of these versions are actually
+
+41
+00:02:02,930 --> 00:02:06,080
+pushed to the repository that is seeable to the whole world.