Warm-up Unix

Suspending a running process

• C-z … suspends a process running in the foreground (e.g. top, vim etc.)
• fg … re-start the suspended process again (in the foreground)
• bg … re-start the suspended process in the background
  • very useful for a longer running computation or script

find -criterion 'value' [-exec ;]

• find . -name '*.t.gz' … all files in this directory, recursively

xargs

• execute the command that follows for every file received from the pipe find . -name *.html | xargs grep 'UFAL'

process substitution (almost like a temporary file)

• <(command) … make command output appear as a file
• use for arguments of commands that require files as arguments
• no need to save temporary files and then remove them

diff file1 <(cat xy | sort | uniq -c | sort -nr)

or

start_btred -l <(ls *.t.gz)  -qTe \
'map {print join(", ", ListV($_->{"tnode.rfs"})), "\n" } ListV($root->{mwes})'

Version Control Systems

• file.bak, file.june20, myProject-2014-04-25-9PM.zip etc.
• some Microsoft solutions – lock file for edit, then remove lock
• CVS – used to be popular, now outdated
• SVN
  • popular choice
  • merging changes, not locking
  • central server: one repository
  • local checkouts: snapshots of the central repository state
  • checkout (update), modify, update (resolve conflicts), commit
• distributed VCS (several systems)
  • central server not needed
  • each copy is a full clone, not a snapshot of a state
  • central repository still often used
  • changes applied via:
    • commit rights, or
    • sending and applying patches (git format-patch and apply)
    • pull-requests on Github, Bitbucket, etc.

Git

Most popular Distributed VCS.

• Every copy (clone) keeps the whole history.
  • Works offline (log, commit, diff, branch, etc.)
• More types of workflows possible, which can be confusing.
• Can do a LOT of obscure things (like rewrite history) which can be confusing too.
• Basic handling is SIMPLE:
  1. git init . # start a git repo here
  2. git add * # add everything in here into the project
  3. now modify some file(s), i.e. implement a new function
  4. git diff to check what is new
  5. git commit -am'initial commit' # commit all changes and add this message
• sync local changes with a remote repository:
  • git pull and git push # pull/push what from/to where

Very good documentation is in this nice book: https://git-scm.com/book/

VCS + Project management

Some VCS, often support for more choices (SVN, Git, Mercurial, Bazaar), Issue tracker, wiki, sometimes other components. Linking between components: refering to code changes (commits) wrom wiki or issues, linking resolved issues from commit messages, etc.

• As a service
  • Github
  • Butbucket
  • Sourceforge
  • Google Code
• As a software (to install on one's own server)
  • Trac (SVN, Git, ??)
    • svn.ms.mff.cuni.cz/trac
    • quite nice and simple
  • Redmine (Git)
    • redmine.ms.mff.cuni.cz
    • a bit more complex
    • very detailed issue management (time, dependencies, watchers, etc.)

Github Best Practices

Not really just Github. One possible workflow. Makes sense for all big projects.

• Use Issues
  • Give them sensible keywords. E.g. priorities + types: important+bug
• Assign Issues, if there is more than one developer. Even to yourself.
• Use forks and pull requests.
  • Feature (=issue) branches
  • Don't merge your own pull requests, let other team members check them and merge them (or throw them back on your head)
• Tag releases
• Milestones are good for organising issues and keeping track of time. Especially good for comparing plans (planned release dates) to reality.