revision control

 
revision/version ctonrol systems/tools. 
 
there have been many. 
e.g. 
- rcs 
- subversion 
- perforce 
- CVS 
- git 
 
 
################# 
###    RCS    ###   revision control system 
################# 
 
mkdir RCS in a dir, then you can check in/out files. 
(RCS and foo.py in the same dir, as opposed to foo.py in RCS dir) 
 
co -l  foo.py     # check out, lock    # do this before you edit. 
ci -u  foo.py     # check in, unlock.  # this either the first time you register a script into RCS or check in the change you just made. 
rlog  foo.py      # check the revision log 
co -p 1.2 foo.py  # display revision 1.2 of foo.py 
 
rcsdiff -r1.2 -r1.3 foo.py    # diff version 1.2 & 1.3 
rcsdiff foo.py                # this does rcsdiff on the latest and prev revision 
 
rcs -u foo.py     # break a lock by somebody else 
 
 
(ref) http://archive.oreilly.com/pub/a/perl/excerpts/system-admin-with-perl/five-minute-rcs-tutorial.html 
 
note: as above, it is primitive. 
 
 
####################### 
###    perforce     ### 
####################### 
 
there are a few steps. 
 
(1) installation:  assuming this is already done by your admin 
(2) setup: you set up your client/config, and some dir mapping. 
 
e.g. 
 
P4CONFIG=/foo/bar/.p4settings    # which should have the following env vars specified 
                                 # often you can reference your team mate's config 
P4USER 
P4DIFF 
P4CLIENT=kenics_ws 
P4HOST 
P4PORT 
P4EDITOR     # emacs, vi, etc 
P4CHARSET 
P4MERGE 
P4PASSWD 
 
 
then run p4 client, then you can edit your client info. 
 
e.g.                        # again you can often reference your team mate's config 
 
Client:  kenics_ws 
Owner: kenics 
root: /usr/kenics/    # top dir of your work space 
Options: noallwrite noclobber nocompress unlocked nomodtime normdir    # see ref link for more options 
SubmitOptions: submitunchanged 
LineEnd: unix 
View: 
   //etc/shared/prod/...  //kenics_ws/prod/... 
   //foo/bar/...  //kenics_ws/bar/... 
 
 
 
(ref) https://www.perforce.com/perforce/r10.2/manuals/p4guide/02_config.html 
 
p4 login    # make sure you have P4PASSWD set  or you can specify -p your_pw 
 
### 
### (3) using p4  :  finally, we can actually use p4, to revision control 
### 
 
p4 login 
 
p4 -c shared_prod add -f //etc/shared/prod/foo.py    # to initially add a file into a depot (depot == repository in p4) 
                                                     # you probably may have to do some more config with depot. 
cd /usr/kenics/kenics_ws/prod/ 
p4 -c kenics_ws sync //etc/shared/prod/foo.py          # -c client_name 
p4 -c kenics_ws edit foo.py 
emacs foo.py 
p4 -c kenics_ws revert foo.y 
p4 -c kenics_ws submit foo.py 
p4 -c shared_prod sync [-n] foo.py     # -n is dry-run 
 
p4 filelog foo.py            # if you set foo.py#5 , then it looks fifth rev in depot or older 
p4 grep -e pattern foo.py    # pattern can be a simple string "helloworld", also you can use the usual grep options like -i, -n, -v, -l 
                             # foo.py here means grep for all revisions of foo.py, or you can specify foo.py#5 then it greps fifth or older revs. 
p4 diff foo.py#5             # compare foo.py in client workspace with the fifth depot revision 
p4 diff2 foo.py#5 foo.py#6   # diff revision 5 & 6 in depot 
p4 print foo.py#5            # print foo.py, fifth rev in depot 
 
 
see the ref for more features like wildcard, etc 
 
(ref) https://www.perforce.com/perforce/r15.1/manuals/p4guide/chapter.usingp4.html 
(p4 grep) https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_grep.html 
 
 
 
################### 
###    git     #### 
################### 
 
e.g.  https://github.com/etlfs    # github is a repo hosting service 
 
 
## 
##  how to install git   (ref) https://git-scm.com/book/en/v2/Getting-Started-Installing-Git 
## 
 
$ which git 
/usr/bin/git 
 
## 
##  .gitconfig 
## 
 
$ cat /home/kenics/.gitconfig 
user.name=kenics 
user.email=foobar@foobar.com 
core.editor=emacs 
 
## 
##  man page 
## 
 
google or run the below help command. 
 
$ git help <verb>    # usually very well written, with examples 
e.g. 
git help init 
git help add 
git help push 
 
 
### 
###  basic workflow 
### 
(ref) https://guides.github.com/activities/hello-world/ 
 
### 
###  (1) create a repository 
### 
 
normally, a repository == a project 
then you have your code/cfg/doc files. 
 
create a new repo. 
at this point, you only have master branch. a branch is like a copy. 
 
### 
###  (2) create a branch 
### 
 
basically, you make a copy of master branch. 
you can make multiple branches if you need. 
 
suppose 5 people created a branch off of the same master branch. 
(presumably because people are working on the same project, each adding new features, etc) 
 
### 
###  (3) edit files, then stage/commit changes (saves your change in your branch) 
### 
 
### 
###  (4) make a pull request 
### 
 
here, you advertize your change to others so they can review diff and decide to merge your change into their branch. 
(or maybe after approval, your pull request gets merged into the master branch, then people merge that into their branch) 
 
### 
###  (5) merge a pull request (either to your branch or master branch) 
### 
 
 
 
### 
### [example] create a new repo 
### 
 
create a new repo (named, let's say "bubble") on github.  # then you get the URL for this repo. e.g. https://github.com/etlfs/bubble.git 
 
then locally, on a unix machine, you have files you wanna add to the above bubble repo on github. 
e.g. 
/home/kenics/proj/bubble/* 
 
# then you do the following: 
 
$ cd /home/kenics/proj/bubble 
$ git init                      # this creates /home/kenics/proj/bubble/.git  which creates some index, meta-ref files, etc 
$ git add .                     # this stages every file under . 
$ git commit -m "your_first_commit_message" 
 
# at this point, you have a new repo locally. 
# now you want to push the files to the remote repo bubble. 
 
$ git remote add origin https://github.com/etlfs/bubble.git    # this basically recognizes a remote repo under an alias origin == https://github.com/etlfs/bubble.git 
 
# because "origin" is just an alias, you can use other alias name instead, and also you can use actual URL instead. 
 
$ git remote rename origin foobar      # you can rename the alias origin to foobar 
 
# finally, push your files into the remote repo 
 
$ git push origin master     # git push <remote_repo_name> <branch_name> 
                             # here alternatively, you could run 
                             # git push https://github.com/etlfs/bubble.git master 
 
 
### 
###  fork/clone a repo 
### 
 
when you want to work on files, you want your own branch, but to have a local branch, you really need a local copy of the repo. 
so we say fork/clone a repo. 
 
$ git clone https://github.com/etlfs/bubble.git  /home/kenics/proj/bubble     # git clone <repo_URL> <local_dir_name> 
                                                                              # creates a clone into a local dir 
$ cd /home/kenics/proj/bubble 
$ git status 
# on branch master                                # as you can see, you are on master branch by default 
nothing to commit (working directory clean) 
 
# now you can create branches within your local repo. 
$ git branch a_test_branch master            # this creates a new branch named a_test_branch based on master branch 
                                             # if you simply run git branch a_test_branch   then it bases off of the current branch you are on 
$ git checkout a_test_branch                 # moves into a_test_branch 
 
$ git checkout -b a_test_branch master       # combines the above two commands 
Switched to a new branch 'a_test_branch'     # "-b" says create a new branch 
                                             # git checkout -b <new_branch_name> <base_branch_name> 
                                             # you can also run  git checkout -b a_test_branch origin/master 
 
 
$ emacs some_file.py 
$ git add some_file.py                         # you can use regex 
$ git commit -m "description_of_your_change"   # or you can use "-a" in git commit, to get all changes (updated files, deleted files) 
 
$ git checkout master      # switch to master branch 
$ git merge a_test_branch  # this merges a change you made (commited) in a_test_branch, into master branch (i.e. productionizing) 
 
$ git branch -d a_test_branch   # deleting a_test_branch, because its change is merged into master and we don't need this test branch any more. 
 
# NOTE:  git status  is always helpful. tells you which branch you are on, which files are [un]staged, not-committed yet, etc 
 
$ git branch            # these two commands are the same 
$ git branch --list     # listing the local branches 
$ git branch -a         # list all local+remote branches 
 
 
## 
## push your changes to GitHub 
## 
 
$ git remote add origin https://github.com/etlfs/bubble.git 
$ git push origin master 
 
 
## 
##  fetching/merging 
## 
 
$ git fetch origin master    # fetch/download files from master (of repo named origin) 
$ git merge origin/master    # updating your current local branch with the latest files from origin/master 
                             # "git pull" actually does fetch+merge from origin, but sometimes behaves unexpected, so safer to explicitly fetch+merge 
 
 
## 
##   sending a pull request (GitHub) 
## 
 
while there are ways to do this on command line, not fully natively supported like other operations. 
looks like the easiest way is to do it in GitHub GUI 
https://help.github.com/articles/about-pull-requests/ 
 
it's basically asking the original repo owner to pull your fork. 
 
 

  1. 2017-12-22 00:08:05 |
  2. Category : misc
  3. Page View:

Google Ads