Changing the way you learn

Question	Answer
Version Control, A.k.a. (nefndu 5)	-Version Control System -Revision Control -Source Code Management -Source Control -Code Repository
Local Version Control kerfi	-er ekki með neinum deilingarmöguleika -það að geyma allar útgáfur, allar breytingar á öllum skrám sem þú ert að vinna með .-þú ert bara á þinni eigin vél og heldur utan um það. -Eitt frægt kerfi er rcs
Centralized Version Control kerfi	-þá ertu alltaf með eitthvern server og þetta er bara client server útgáfa. -clientinn talar alltaf við serverinn -allar breytingar sem við gerum þá eigum við alltaf samskipti við serverinn -þannig ef að við breytum eitthverju og framkvæmum commit þá er það framkvæmt á serverinn og allir aðrir geta séð þá að það er komin ný útgáfa
Distributed Version Control kerfi	-er nýjast og virðist vera ná mestu útbreiðslu -Það er ekkert server eða client þannig hver einasti aðili sem notar distributed kerfin hann er bara með ALLT kerfið keyrandi. -git er distributed -In a distributed model, every developer has their own repo
Version Control Benefits	-Backup and Restore -Synchronization -Short-term undo -Long-term undo -Track Changes -Track Ownership -Sandboxing -Branching and merging
Sandboxing	-insurance against yourself -gera breytingar á kóða í þínu umhverfi án þess að eiga á hættu að skemma fyrir öðrum, geta testað og leyst villur áður en þú "checking in".
Branching and merging	-a larger sandbox. -getur branchað afriti af kóðanum þínum inn á afmarkað svæði og aðlagað og lagfært villur áður en "checking in" your changes.
Repository	-þar sem öll gögn eru geymd, oft á server. -A collection of commits, and branches and tags to identify commits
Working copy	-The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. -Conceptually, it is a sandbox
"Check out"	-To create a sandbox, check out a copy of the repository. -In some version control systems, this term means "update and lock”.
Locking	-virkar í rauninni þannig að þegar ég er að fara vinna með eitthverja skrá, þá get ég sett lás á þá skrá, þannig að á meðan ég er að vinna í henni þá getur enginn annar unnið í henni. -skapar samt í raun fleiri vandamál heldur en þeir leysa. Þeir leysa í raun bara þetta eina atriði. -Það getur verið mjög heftandi að bara einn getur verið að vinna í skjalinu í einu.
Non-locking	-Allows editing of any file at any time -Eliminates waiting for locks -Only for text files -Requires occasional conflict resolution
Trunk	-The unique line of development that is not a branch -: Það er stofn eins og á tré, ef það eru greinar(branches) -trunk er svona meginlínan sem allir eru að þróa eftir. -Þar er aðal. -Stundum kallað Mainline eða Baseline
Branch	A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may be developed at different speeds or in different ways independently of the other.
Tag	-Þegar við gefum eitthverri ákveðinni útgáfu af kerfinu eitthvað gáfulegt nafn -A tag or release refers to an important snapshot in time, consistent across many files.
Commit	-occurs when a copy of the changes made to the working copy is written or merged into the repository. -(check-in, install or submit)
Add	-Put a file into the repo for the first time, i.e. begin tracking it with Version Control. (It Git you need to add a file every time it changes).
Head	-The most recent commit. -Sometimes called tip.
Revision	-er nafn yfir þessa ákveðnu útgáfu, hvaða skrá tilheyra þessari ákveðnu útgáfu það er yfirsjónin.
Change	A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems.
Change list	On many version control systems with atomic multi-change commits, a changelist, change set, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing source to be examined as of any particular changelist ID.
Merge	-A merge or integration brings together two sets of changes to a file or set of files into a unified revision of that file or files
Conflict	tvær ólíkar breytingar á sömu skránni.
Revert	Revert your sandbox to throw away your changes and return to the point of your last update. This is handy when you've broken your local build and can't figure out how to get it working again. Sometimes reverting is faster than debugging, especially if you have check in recently.
Rollback	Roll back a check-in (commit) to remove it from the tip of the repository. The mechanism for doing so varies depending on the version control system you use.
Version Control Limitations	-þetta er fyrst og fremst bara hugsað fyrir texta-filea, eins og source file-ar eru. -source file-ar eru bara hreinar texta skrár og öll source control kerfi kunna yfirleitt bara að vinna með texta skrár. -Branching and merging cannot be fully automated
When there is a conflict, the VCS may report a conflict and not let you commit — it’s up to you to commit a newer version that resolves this dilemma. A few approaches:	Re-apply your changes. Sync to the the latest version (r4) and re-apply your changes to this file: Add hot dog to the list that already has cheese. Override their changes with yours. Check out the latest version (r4), copy over your version, and check your version in. In effect, this removes cheese and replaces it with hot dog. Override your changes with their.
Not the (main) purpose of VCS:	To manage project management artifacts Task breakdown (Verkáætlanir) Planning (Tímaáætlanir) Time tracking (Tímaskráningu) To manage generated artifacts Executable files (Keyrsluskrár) Compiled documents (Samsett skjöl) To manage temporary information
Centralized version control focuses on :	-synchronizing, -tracking, -backing up files
Distributed version control focuses on :	-sharing changes; -every change has a guid or unique id.
Centralized VCS are not good in	-merging and branching
Distributed systems make branching and merging :	-painless because they rely on it.
push:	send a change to another repository (may require permission)
pull:	grab a change from a repository
Distributed Version Control Key Advantages:	-Everyone has a local sandbox -It works offline -It’s fast -Diff, commits and reverts are all done locally -It handles changes well -Built around sharing changes (each change has guid) -Branching and merging is easy -every developer “has their own branch” -Less management -No “always-running” server software to install D-VCSes may not require you to “add” new users (pull URLs)
Distributed Version Control Key Disadvanges:	-You still need a backup -There’s not really a “latest version” -A central location helps clarify what the -latest “stable” release is. -There aren’t really revision numbers -Every repo has its own revision numbers, instead, people refer to change numbers (guid’s) -Thankfully, you can tag releases with meaningful names -Distributed systems have no forced structure -You can create “centrally administered” locations or keep everyone as peers

Next up

Version Control

Description

Resource summary

Similar

	Created by Kristin Sif Vigfusdottir about 8 years ago